HP-UX 

System Administrator Manual 

HP 9000 Series 500 Computers 

HP Part Number 97089-90059 



HEWLETT 

PACKARD 


Hewlett-Packard Company 

3404 East Harmony Road, Fort Collins, Colorado 80525 




NOTICE 

The information contained in this document is subject to change without rxjtice. 

HEWLETT-PACKARD MAKES NO WARRANTY OF ANY KIND WITH REGARD TO THIS MANUAL, INCLUDING, BUT NOT LIMITED TO, 
THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE Hewlett-Packard shall not be liable 
for errors contained herein or direct, indirect, special, incidental or consequential damages in connection with the furnishing, performance, 
or use of this material. 

WARRANTY 

A copy of the specific warranty terms applicable to your Hewlett-Packard product and replacement parts can be obtained from your local 
Sales and Service Office. 


Copyright 1986, 1987 Hewlett-Packard Company 

This document contains proprietary information which is protected by copyright All rights are reserved. No part of this document may be 
photocopied, reproduced or translated to another language without the prior written consent of Hewlett-Packard Company. The information 
contained in this document is subject to change without notice. 

Restricted Rights Legend 

Use, duplication or disclosure by the Government is subject to restrictions as set forth in paragraph {bK3KB) of the Rights in Technical Data and 
Software clause in DAR 7-104 9(a). 

Use of this manual and flexible discfs) or tape cartridge(s) supplied for this pack is restricted to this product only. Additional copies of the programs 
can be made for security and back-up purposes only. Resale of the programs in their present form or with alterations, is expressly prohibited. 

Copyright 1980, 1984, AT&T, Inc. 

Copyright 1979, 1980, 1983, The Regents of the University of California 

This software and documentation is based in part on the Fourth Berkeley Software Distribution under license from the Regents of the University 
of California 






Hewlett-Packard is in the process of changing the color of our documentation binders. In order 
to accomplish this changeover we are placing two spine inserts with this manual. Please use the 
insert that matches the binders you receive. 


Hewlett-Packard Company • 3404 East Harmony Road • Fort Collins. Colorado 80525 


Printed in U S A 







Printing History 


New editions of this manual will incorporate all material updated since the previous 
edition. Update packages may be issued between editions and contain replacement and 
additional pages to be merged into the manual by the user. Each updated page will be 
indicated by a revision date at the bottom of the page. A vertical bar in the margin 
indicates the changes on each page. Note that pages which are rearranged due to changes 
on a previous page are not considered revised. 

The manual printing date and part number indicate its current edition. The printing 
date changes when a new edition is printed. (Minor corrections and updates which are 
incorporated at reprint do not cause the date to change.) The manual part number 
changes when extensive technical changes are incorporated. 

July 1986...Edition 1 
April 1987...Edition 2 

Updated to reflect HP-UX 5.2 software changes. 


Printing History iii 




IV 



Table of Contents 


Chapter 1: Getting Started 

Welcome. 1 

What’s In This Manual?. 1 

Conventions Used in this Manual .3 

Naming Conventions.3 

Keyboard Conventions.. = = 4 

Using Other HP-UX Manuals.4 

Single-user vs. Multi-user Systems.4 

The Administrator’s Responsibilities .5 

Installing and Testing the Hardware.5 

Installing the HP-UX Operating System.5 

Evaluating Users’ Needs.5 

Configuring HP-UX.6 

Allowing Users Access to the System.6 

Adding and Moving Peripheral Devices.6 

Monitoring File System Use and Growth.6 

Updating the HP-UX System. 7 

Backing Up and Restoring the System.7 

Detecting/Correcting File System Errors.8 

Assisting Other Users .8 

Providing a “Back-up” Administrator.8 

User Survey.9 

Chapter 2; Installing HP-UX 

Installation Overview/Checklist. 11 

Before Installing HP-UX. 12 

System Distribution Media. 12 

Check the Read Me First Document. 12 

System Console. 13 

Verify the Hardware. 14 

Installation. 17 

Load the First “Installation” Tape. 17 

Begin the Installation . 18 


Table of Contents v 


































Using Your System.30 

Setting Minimum Protections.30 

Setting the System Clock.31 

System Administrator Tasks.33 

Moving On.35 

Installation Troubleshooting Hints .36 

Problems Initializing the Destination Device.36 

Problems While Loading From the Installation Tapes. 37 

Chapter 3: Concepts 

Processes.41 

Process Creation.41 

(Parent and Child Processes).41 

Process Termination.43 

Process Groups.43 

Terminal Affiliation.44 

Open Files in a Process.44 

IDs .45 

The Super-User.46 

File System Implementation.47 

The Volume Header.53 

File Format and Compatibility . 53 

File Protection .54 

File Sharing and Locking .58 

Magnetic Tape .61 

Magtape Definitions.61 

Preventive Maintenance.65 

Tape Streaming.65 

Memory Management .69 

Memory Allocation.69 

Virtual Memory .73 

Shared Code.76 

Demand Load. 78 

Paged External Data Segments.79 

Combining Memory Management Tools.82 

The Buffer Cache.83 

Peripheral Device I/O.85 

Device Classes.85 

Drivers.86 

The HP-UX Hierarchy.87 


vi Table of Contents 









































Chapter 4: System Startup and Shutdown 

System Startup Functions.92 

Booting the System. 92 

Overview of Internal Functions of System Startup.94 

The Boot ROM.95 

HP-UX Takes Control.96 

HP-UX Starts the Init Process..97 

Init Brings the System to Run-Level 2.98 

Init Spawns gettys to Cause a Login Prompt.99 

A User Logs In. 101 

System Administration Mode. 105 

Booting Problems. 105 

Shutting Down the System. 106 

Power Fail or Disk Crash Recovery. 109 

Chapter 5: The System Administrator’s Toolbox 

Adding/Moving Peripheral Devices. 113 

Overview of the Task. 114 

Determining the Peripheral’s Location. 115 

Connecting the Peripheral. 116 

Block versus Character Device Files. 116 

Creating Device Files. 117 

Using the mkdev Script. 118 

Using mknod with the Supplied Tables . 120 

Miscellaneous Devices. 124 

Memory Volumes. 125 

Terminals and Modems. 126 

Consoles. 132 

Pseudo Terminals. 133 

Hard Disks, Flexible Disks, and Cartridge Tapes. 134 

Nine-Track Magnetic Tape. 138 

Printers . 141 

Plotters and Digitizers. 145 

Adding/Removing Users. 147 

Creating the /etc/passwd Entry. 147 

The “Makeuser” Script. 149 

The Step-by-Step Method. 150 

Setting the New User’s Password. 152 

Removing a User from the System . 153 

Suspending a User from the System. 153 

Adding to /etc/checklist. 154 


Table of Contents vii 









































Backing up and Restoring the File System. 156 

Backup Strategies and Trade-offs . 156 

Things to Consider about File System Backups. 158 

Performing a System Backup. 160 

Backing Up Selected Files onto Flexible Disk or Magnetic Tape.163 

Backing up Selected Files onto Cartridge Tape. 164 

Restoring the System. 164 

Diagnostics. 168 

Performing Backups Automatically. 168 

Changing a Password. 170 

Changing and Creating System Run-Levels. 171 

Changing the System’s Run-Level. 172 

Re-reading /etc/inittab. 173 

Creating New System Run-Levels. 173 

Example/etc/inittab. 175 

Changing the HP-UX Environment Files. 176 

/etc/inittab. 176 

/etc/rc. 176 

/etc/passwd. 177 

/etc/group. 177 

/etc/motd . 177 

/usr/news. 177 

/etc/profile or /etc/csh.login. 178 

/etc/utmp. 178 

/etc/wtmp. 178 

/etc/btmp. 178 

/etc/secure! ty. 179 

$HOME/.profile, $HOME/.cshrc, $HOME/.login . 179 

$HOME/.exrc. 180 

/usr/lib/terminfo. 180 

/etc/checklist. 180 

/etc/catman. 181 

/etc/issue. 182 

/etc/csh.login, /etc/rc. and /etc/profile. 182 

/usr/lib/tztab. 183 

/etc/tty type. 183 

/usr/adm/errfile. 183 

Communicating with System Users. 184 


viii Table of Contents 









































Configuring the HP-UX Operating System. 185 

Configurable Attributes. 185 

How to Configure Your Operating System. . 188 

Setting the Default Configuration Parameters.189 

Controlling Disk Use. 190 

Creating File Systems. 191 

Creating Groups/Changing Group Membership = = = .. 193 

Creating and Using a Recovery System .. 194 

When to Create/Recreate the Recovery System. 194 

Creating a Recovery System. 195 

Using the mkrs Script. 197 

Booting the Recovery System. 198 

Shutting Down the Recovery System. 199 

Using the Recovery System. 199 

Notes on the System Console Device .203 

Media Utilities .205 

Initializing Media.205 

Initializing Disks to SDF Format.206 

Initializing Media to LIF Format.209 

Commands and Utilities to Transfer Files.211 

Commands to Monitor Your File System.216 

Commands to Verify the Integrity of your Media.216 

Modifying the Boot Area .217 

How to Add Segments.217 

Removing Segments.218 

Replacing Segments.219 

Checking the Boot Area. 219 

Optional System Segments.219 

Mounting and Unmounting File Systems. 221 

To Mount a File System. 222 

To Unmount a File System.225 

Errors.226 

Mounting/Unmounting File Systems Using /etc/checklist.227 

New Naming Conventions for Device Files.228 

Removing Optional Products and File sets.231 

Setting the System Clock.232 


Table of Contents ix 







































Setting Up the LP Spooler.235 

What is in this Section.235 

LP Spooler Terminology and Overview .236 

Installing the LP Spooler .237 

Example.240 

General-Purpose LP Spooler Commands.241 

System Administrator LP Spooler Commands.241 

Other LP Spooler Adminstrator Duties.242 

How Models Work.246 

Updating HP-UX and Installing Optional Products .247 

Preparing to Update .247 

Locate and Write-protect the Product.249 

Load the Update Tools.249 

Perform the Update.250 

Using Optinstall to Install Optional Products.258 


Chapter 6: System Accounting 

What Is in This Chapter?.264 

Installation and Daily Usage .265 

How to Install System Accounting .265 

Summary of Daily Operation.268 

Overview of System Accounting.269 

Definitions. 270 

Introduction to Commands.272 

System Data Flow .276 

Login and Directory Structure.278 

Disk Space Usage Accounting.281 

Reporting Disk Space Usage.281 

Creating Total Accounting Records .284 

Connect Session Accounting.286 

Writing Records to wtmp — acctwtmp.286 

Displaying Connect Session Records — fwtmp.287 

Fixing wtmp Errors wtmpfix.289 

Creating Total Accounting Records .289 


X Table of Contents 



































Process Accounting .293 

Turning Process Accounting On .293 

Turning Process Accounting Off.295 

Checking the Size of pacct .296 

Displaying Process Accounting Records acctcom.298 

Command Summary Report — acctcms.307 

Creating Total Accounting Records .311 

Charging Fees to Users — chargefee.313 

Summarizing and Reporting Accounting Information.314 

Displaying Total Accounting Records prtacct.314 

Merging Total Accounting Files — acctmerg.317 

Creating Daily Accounting Information — runacct .319 

Displaying runacct Reports — prdaily .325 

Creating Monthly Accounting Reports — monacct .327 

Updating the Holidays File.329 

Fixing Corrupted Files .330 

Fixing wtmp Errors.330 

Fixing tacct Errors.331 

Sample Accounting Shell Scripts.332 

grpdusg.332 

acct^bill.334 

System Accounting Files.337 

Files in the /usr/adm directory.'.337 

Files in the /usr/adm/acct/nite directory.337 

Files in the /usr/adm/acct/sum directory.338 

Files in the /usr/adm/acct/fiscal directory.339 

Appendix A: Using the FSCK Command 

Introduction.341 

Updating the HP-UX File System.342 

Super-Block.342 

I-nodes.343 

File Attributes File.343 

Data Blocks.344 

Free Map Blocks.344 

Corruption of the File System.345 

Improper System Shutdown and Startup.345 

Hardware Failure.345 


Table of Contents xi 







































Detection and Correction of Corruption.346 

File-System Size and I-node-List Size.346 

Free Map.347 

Executing the FSCK Command.348 

A Walk Through.351 

FSCK and Virtual Memory .358 

Appendix B; System Loader Messages 

Introduction.359 

Messages.360 

Glossary.363 

Subject Index.371 


xii Table of Contents 













Getting Started 


Welcome 

This manual is written for you, the Series 500 HP-UX system administrator. Although 
some familiarity with computers is assumed, this manual will serve people with varying 
levels of expertise. If you are already a UNIX^ expert, you will find much here that 
is familiar but may well encounter something new. The HP-UX Operating System is 
composed primarily of Bell Laboratories’ System V.2 UNIX. However, Hewlett-Packard 
has incorporated its own extensions as well as features from the University of California 
at Berkeley Unix 4.1 and 4.2 BSD (Berkeley Systems Distribution) systems and from 
Bell’s System V UNIX. 

Who is the system administrator? The system administrator is the person responsible 
for installing the HP-UX Operating System software, updating the software, tuning the 
system for optimum performance, maintaining the system, and repairing the system 
when something goes wrong. Additionally, the system administrator should become an 
HP-UX “guru”, the local expert to whom other HP-UX users go for help. 


What’s In This Manual? 

This manual is a guide designed to help you fulfill your duties as system administrator. 
The following is an overview of the chapters in this manual. 

Chapter 1: Getting Started 

This chapter provides an overview of the System Administrator Manual^ explains the 
conventions the manual uses, mentions other manuals which will aid you in administrative 
tasks, points out differences between single-user and multi-user systems, and discusses 
the system administrator’s responsibilities. 


^ UNIX is a trademark of AT&T Bell Laboratories. 
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Chapter 2: Installing HP-UX 

This chapter defines terminology used throughout the manual, provides step-by-step 
instructions for installing the HP-UX Operating System software and explains what to 
do after the system has been successfully installed. 

Chapter 3; Concepts 

Certain concepts used and implemented in HP-UX must be understood by the system 
administrator. This chapter discusses such concepts as processes, IDs, the super-user, 
block and character input/output, the file system and its use of mass storage devices, 
compatibility issues, file protection, and memory management. 

Chapter 4: System Startup and Shutdown 

Many things happen between the time you power up the computer running HP-UX and 
the time a user has logged in (gained access) to the system. This chapter examines what 
happens in the HP-UX system. It also describes the proper method of shutting down 
the system. 

Chapter 5: The System Administrator’s Toolbox 

Arranged alphabetically by task, this chapter contains instructions for accomplishing 
tasks the system administrator generally performs. It also includes a list of environment 
files you may wish to customize. 

Chapter 6: System Accounting 

As system administrator you may want to periodically evaluate how well your Series 
500 HP-UX system is operating, as well as how many resources those logging onto your 
system are using. This chapter discusses the various accounting features available on 
HP-UX, how to install them and how to produce various useful reports. 
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Conventions Used in this Manual 


Naming Conventions 

The following naming conventions are used throughout this manual. 

• Italics indicate titles of manuals. The parenthetic number shown for commands, 
system calls and other items found in the HP-UX Reference is a convention used 
in that manual. 

• The first time a file is mentioned, the complete pathname is given; subsequent 
references to that file contain only the final file name unless there is some chance of 
ambiguity. For example, /etc/profile is used instead of profile to avoid possible 
confusion with a user’s personal .profile file. 

• Boldface is used when a word is first defined (as flebnee) and for general emphasis 

(do not touch). 

• Computer font indicates a literal either typed by the user or displayed by the 
system. This includes all command names, system calls, and path names. Keys are 
shown capitalized and enclosed in an oval. A typical example is: 

fsck /dev/7912 | Return | 

Note that when a file name is part of a literal, it is shown in computer font and not 
italics. However, if the file name is symbolic (but not literal), it is shown in italics 
as the following example illustrates. 

fsck device_file_name \ Return | 

In this case you would type in your own device^fHe_name. 

• Environment variables such as PATH or MAIL are represented in uppercase char¬ 
acters. 

• Unless otherwise stated, all references such as “see the login(l) entry for more 
details” refer to entries in the HP-UX Reference manual. Some of these entries 
will be under an associated heading. For example, the chgrp(l) entry is under the 
chown(l) heading. If you cannot find an entry where you expect it to be, use the 
HP-UX Reference manual’s permuted index. 
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Keyboard Conventions 

While installing the HP-UX system, you need to know about two keys: | Back space | 
and I Return | . The | Back space | key will let you fix typing mistakes made when entering 
information. Press | Back space | to ‘'back up” over a mistyped letter. 

Most information typed at the system console must be followed by the | Return | key. All 
Hewlett-Packard terminals supported by HP-UX have a | Return | key. 


Using Other HP-UX Manuals 

Besides this manual, three other manuals will aid you in your system administrator tasks: 

• The Installation Guide for your specific Series 500 computer contains instructions 
for installing the computer hardware, interface cards, and peripherals. The guide 
supplies all the hardware-specific information needed to set up the HP-UX system. 

• The HP-UX Reference contains the syntactic and semantic details of all commands 
and application programs, system calls, subroutines, special files, file formats, mis¬ 
cellaneous facilities, and system maintenance procedures available on the Series 500 
HP-UX Operating System. Use this manual when looking for complete specifica¬ 
tions of a given command, special file, etc. 

• The set of HP- UX Concepts and Tutorials contains information on a broad range 
of HP-UX topics and tools. Several sections may be of particular interest to you: 
Serial Network Communications, The Bourne Shell, The Model 520 Console, and 
vi. 


Single-user vs. Multi-user Systems 

The Series 500 HP-UX Operating System is supplied as either a single-user or multi-user 
system (with a 16, 32 or 64 user license). The difference between the two types of systems 
is implied by their names — a single-user system can only be used by one person at a 
time; a multi-user system, by many at a time. 

If you have a single-user system, many of the multi-user topics covered in this manual 
will still benefit you. Consider a discussion on how to set up and configure the LP 
Spooler (used to control line printer spooling). While this topic may be more critical in 
multi-user systems (where the demand on system resources is generally higher), using 
the LP Spooler on a single-user system can increase the performance and flexibility of 
that system. 
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If you have a single-user system and a procedure or task seems irrelevant, you probably 
can ignore it. Don’t reject multi-user topics too quickly though — they often contain 
information useful for single-user systems. 


The Administrator’s Responsibilities 

This section contains a brief discussion of the system administrator’s responsibilities and 
tells you where to find related information. 

Installing and Testing the Hardware 

As system administrator, you should make sure that your computer is installed and 
operating properly by using the instructions and tests in the installation guide supplied 
with your computer. The computer hardware must function properly before HP-UX is 
installed. 

Installing the HP-UX Operating System 

The HP-UX Operating System is supplied on a V 4 -inch cartridge tape and installed 
using a Command Set ’80 (CS/80) hard disk drive. As system administrator, you are 
responsible for installing HP-UX. Instructions for accomplishing this task are provided 
in chapter 2, “Installing HP-UX”. 

Evaluating Users’ Needs 

Once HP-UX is installed, you should analyze the intended uses of the system. Knowl¬ 
edge of the number of users, the characteristics of each user, the system resources and 
peripherals required by each user, and the data/programs that must be shared by various 
user groups, will help you set up HP-UX for optimum performance. This also applies to 
single-user systems. 

To aid you in this analysis, a sample user-survey form is provided at the end of this 
chapter. You may want to modify this survey to fit your particular needs. Most users 
think in terms of “I need to do this job” not “I need FORTRAN, Graphics, a plotter, 
and 500 000 bytes of data storage.” The survey should help you identify the needs of the 
system users and translate those needs into data relevant to system configuration. 
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Configuring HP-UX 

How the operating system uses computer resources depends on certain values and config¬ 
urations that you control. Configuring the system influences its efficiency and response 
time. Once familiar with the system, you can use the instructions in chapter 5, ‘‘The 
System Administrator’s Toolbox”, to alter the system configuration. 

Allowing Users Access to the System 

Once HP-UX is installed, you are responsible for modifying the operating system to 
allow access by other users. This involves providing each user a user name, a password, 
and a portion of the file system for his use. Instructions for adding users and assigning 
passwords are contained in chapter 5, “The System Administrator’s Toolbox”. 

Adding and Moving Peripheral Devices 

Another of your responsibilities is to add/move peripherals (printers, terminals, mass 
storage devices, etc.) to the HP-UX system as they are required. A list of peripher¬ 
als supported by the Series 500 HP-UX system can be foimd in the HP 9000 Series 
500 Configuration Information and Order Guide supplied with your system. Directions 
for installing the peripherals can be found in chapter 5, “The System Administrator’s 
Toolbox”. 

Monitoring File System Use and Growth 

As HP-UX is used, more and more files are added to the file system. If unused files are 
not removed, the amount of space required to store the files eventually exceeds available 
space. One of your responsibilities is to monitor the size of the file system and identify 
unused files. Unused files should be archived (if needed in the future) and then removed 
from the file system. Also, you should watch for files that continually increase in size. 
Consult the file’s owner to ensure that the file is needed and to see if its size can be 
reduced. Instructions for monitoring the use and growth of the file system are supplied 
in chapter 5, “The System Administrator’s Toolbox”. 
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Updating the HP-UX System 

You will receive software updates by purchasing HP support services that provide periodic 
updates. These updates modify existing capabilities and add new capabilities, ensuring 
that your system contains the latest version of the software. 

As system administrator, you are responsible for installing each software update. You 
should update the manuals to include the documentation changes provided with each 
update and keep a log showing when the update was installed. Notify all system users 
of the changes caused by the update. Because each update depends on changes made 
by the previous update, it is imperative that each update be installed when it arrives. 
Instructions for installing updates are in chapter 5, “The System Administrator’s Tool¬ 
box”. 

Backing Up and Restoring the System 

The HP-UX Operating System, programming languages and applications software rep¬ 
resent a large investment of time and money. Files can be unintentionally removed and 
each access to the system provides an opportunity for error. A critical error can cause 
additional errors in the file system and, when the system becomes sufficiently corrupt, 
file system errors increase rapidly. 

Loss of the system can also occur through unwelcome circumstances (such as spilled 
coffee, smoke contamination, dust or fire) by damaging a mass storage device, its media, 
and/or the data it contains. 

As system administrator, you should make a backup - a copy of the HP-UX Operating 
System, file system and programming languages. Depending on your system usage, 
consider backing up the system on a daily basis. Generally, base the frequency of your 
system backups on the answer to the question “How much data can I afford to lose?”. 

If your system is destroyed, you can recover by restoring the latest version of your system 
backup. If a user accidentally removes a needed file, the file (or a previous version of 
it) can be recovered by copying it back into the file system from the backup. Note that 
a system backup is the only way to recover a deleted or destroyed file. Instructions for 
using the supplied backup command and the CS/80 Tape Backup utility are given in 
chapter 5, “The System Administrator’s Toolbox”. 
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Detecting/Correcting File System Errors 

Every day the system is used, numerous files are created, modified, and removed; each 
action requires an update to the file system. With each update to the file system, it is 
possible that one or more of the updates could fail (for example, because of abnormal 
system shutdown or abnormal program termination). When an update fails, the file 
system can become corrupt. 

HP-UX provides the fsck command — a program that checks the integrity of a file 
system and (optionally) repairs that system. You should check the file system’s integrity 
on a daily basis as well as each time HP-UX is booted. Continuing to use a corrupt file 
system only further corrupts the system. Instructions for verifying and repairing the file 
system are located in the “Using the FSCK Command” appendix. Also, see the fsck(lM) 
entry in the HP-UX Reference manual. 

Assisting Other Users 

Since you carry the title “System Administrator”, users may come to you for help with 
the system. You should plan on allocating a portion of your time for consulting and 
problem solving. 

If you have purchased certain support services, you have access to direct technical support 
from Hewlett-Packard. As the system administrator, you are the only person authorized 
to use this service. If other system users have difficulty with the system, they should 
direct their questions to you. If you cannot solve the problem, then call your support 
person at HP. 

Providing a “Back-up” Administrator 

At least one other person should be trained as the system administrator to handle your 
responsibilities in the event of your absence. 

To ease your job as system administrator and the job of the “back-up” system admin¬ 
istrator, you should automate as many of your tasks as possible. Chapter 4 (“System 
Startup and Shutdown”) and chapter 5 (“The System Administrator’s Toolbox”) show 
you how to create programs that automatically perform tasks at specific times. By 
scheduling programs using system routines, you can automatically back up the system 
or initiate communications between your system and another HP-UX system (using the 
UUCP utilities). 
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User Survey 


Name_ Location, 

Phone _ 

Location where you will be using the system. 

User Category 

_ Technical Data 

Entry Operator 

_ Secretary - Word 

Processing Operator 

_ General Programmer 

_ System Programmer 

Support Personnel 

Describe your application 

What programming language(s) will you use? _ 

What applications software (such as graphics) will you use ? 


(run existing application programs; 
enter data or automatically read data 
from instrumentation) 

(run existing application programs; 
enter data/text) 

(develop application programs) 

(develop prograims for improving 
computer system performance or 
for use by other programmers) 
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What computer hardware or peripherals will you need to access? 

Thermal printer _ Plotter 

_ Impact printer _ Removable mass storage device 

_ Graphics terminal _ Other _ 

_ Laser printer _ 

Are there other users with whom you want to share programs or 
data? _ 

If so, list them. _ 


Will you be generating or using large amounts of data? _ 

If so, how much must be "on-line" (accessible at all times)? 

What long term data storage does your application require? _ 

How many programs/processes will you be running at one time? _ 
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Installing HP-UX 




This chapter provides a step-by-step procedure for installing the HP-UX Operating Sys¬ 
tem on HP 9000 Series 500 computers, Models 520, 530, 540, 550, and 560. All references 
to HP-UX in this manual apply equally to the Series 500 HP-UX Operating System on 
all the products listed above unless specific variations are noted. 


Installation Overview/Checklist 

For your convenience, here is a checklist of the major steps involved in the installation of 
the HP-UX Operating System. Use this list (or a copy of it) as you follow the instructions 
in this chapter and check off each item as you complete it. 

_ Install and test the hardware 

_ Confirm the part numbers on the HP-UX distribution media 

_ Check the CS/80 switch settings 

_ Confirm proper operation of the computer’s boot ROM 

_ Verify the installation tape is not write-protected 

_ Load the first of the “Series 500 HP-UX Installation” tapes 

_ Follow and respond to the installation utility menus 

_ Remove the second installation tape, storing both tapes in a safe place 

_ Follow the guidelines in the “Using Your System” section 
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Before Installing HP-UX 

Before installing the HP-UX software, the hardware must be installed and tested. This 
includes the computer, the CS/80 disk drive (and its switch settings), and all interface 
and memory cards. The installation manuals that come with each system component 
explain how to install that component; a few critical items are reviewed here. 

This section also contains information about the installation tapes. 

System Distribution Media 

The system is supplied on two HP 88140SC (DC-150) V 4 -inch cartridge tapes for in¬ 
stallation from the cartridge tape drive. Check the product numbers on the cartridge 
tape labels. One must be labeled “Series 500 HP-UX Installation, Tape 1” (contains the 
HP-UX Operating System). The other tape must be labeled “Series 500 HP-UX Instal¬ 
lation, Tape 2”. No other versions of HP-UX are available at this time for the Series 500 
computers listed at the beginning of this chapter. 


Note 

Opening the media envelope indicates your acceptance of the prod¬ 
uct (see the “Limited Warranty” section of the License Agreement 
pamphlet) and your acceptance of the terms of the license agree¬ 
ment. Check the product number BEFORE you open the package. 


Check the Read Me First Document 

If there are known bugs when your system was shipped, they will be described in an 
attachment to the Read Me First document. Follow the instructions in the “Bugs" 
section of the document. The “Bugs” section is provided to give you information on 
problems you may encounter during installation or potentially serious bugs encountered 
after installation. It will also give you a workaround. 
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System Console 

The system console consists of a keyboard and display (or terminal) given a unique status 
by HP-UX. It is associated with the special device file /dev/cocxsols. All boot ROM error 
messages (messages sent prior to loading HP-UX), HP-UX system error messages, and 
certain system status messages are sent to the system console. Under certain conditions 
(for example, the system administtration mode), the system console provides the only 
mechanism for communicating with HP-UX. 


Note 

The conventions for the system console as described here are sig¬ 
nificantly different than in versions earlier than 5.0. 


HP-UX assigns the system console function according to a prioritized search sequence 
when the HP-UX kernel gains control during the boot-up process. On the Series 500, 
the search priority is: 

1. On the Model 520, the keyboard and display associated with the ITE. 

2. The lowest numbered HP 98700 display device with a monitor and keyboard on a 
Model 550 that is currently powered up. 

3. A keyboard and display (terminal) associated with an HP27140A 6-channel mo¬ 
dem MUX, HP 27130B 8-channel MUX card, or an HP 27128A ASI card at minor 
number 0x000000 (the first port on the first slot). 

If none of the above conditions is met, no system console exists. HP-UX does not tolerate 
this, and you cannot use HP-UX without a system console. 

Following the installation or update of your HP-UX system you will have a special device 
file called /dev/systty. This is the device which is usually used for booting HP-UX and 
will usually be linked to /dev/console. 

Another special device file, /dev/syscon, is normally linked with /dev/systty. If the 
super-user issues the init command from a device other than /dev/systty, init will link 
/dev/syscon to the originating device. Whenever the system is rebooted, the original 
location of /dev/syscon will be restored. 
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Note 

To install the HP-UX system it is necessary to communicate with 
the boot ROM and the Series 500 HP-UX Installation Utilities. 
Hence, you must have a supported console as described in order to 
install HP-UX on your Series 500 computer. 


For further information on the system console, see the HP-UX Concepts and Tutorials 
document “HP-UX and the HP 9000 Model 520 As System Console”. For a complete 
list of Hewlett-Packard terminals supported by HP-UX, see the HP 9000 Series 500 
Configuration Information and Order Guide supplied with your system. 

Verify the Hardware 


Note 

If you already have the hardware unpacked and connected, you can 
skip this section. If you do not have the hardware connected, or if 
you wish to recheck your hardware setup, this section offers some 
guidelines. 


With the computer, the CS/80 disk and any other devices attached to the system turned 
off, check the CS/80 switch settings and connections a description and list of CS/80 
devices follows this section). Switch settings are explained in the Installation guide 
supplied with your computer. Your CS/80 device must be connected via either a high 
speed HP-IB interface card (HP 27110A), or the internal medium speed HP-IB interface 
card of the Model 550. The CS/80 device should be connected to the HP-IB interface 
card with an HP-IB cable. The cable connects from the end of the HP-IB card on the 
rear of the Series 500 computer to the port on the rear of the CS/80 device. The HP 7908 
has only a single HP-IB port; use the lower port on the HP 7911, HP 7912, and HP 7914. 

If you arc using an internal cartridge tape drive in your CS/80 disk, and you have 
purchased the dual controller option for that device (two HP-IB connections), the upper 
port connects to the tape drive. In this case you will either need a second HP-IB interface 
card to connect to the tape drive, or you will need a short HP-IB cable to connect the 
lower port to the upper port. If you connect the lower port to the upper port, the 
bus address switch settings for the two ports on the rear of the CS/80 device must be 
different. If the bus address switch settings are the same, your Series 500 computer will 
be unable to determine which device it is talking to, and you won’t be able to continue 
installing HP-UX. 
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CAUTION 

Do not attempt to unpack and connect a CS/80 disk drive (other 
than the HP7908P) yourself. The CS/80 disk drives are packed 
to prevent damage during shipment. To prevent damage to the 
device, an HP Customer Engineer must unpack, install and test 
the device. 


Next, confirm that the bus address switch(es) on the rear of the CS/80 root device (the 
device on which HP-UX is to be installed) is set to zero (0). Instructions for setting the 
switch(es) are in the CS/80 Installation Manual. (The CS/80 Installation Manual refers 
to the bus address as “HP-IB device address”.) 


Note 

Models 530, 540, 550, and 560 must have an HP supported terminal 
installed to function as a system console before continuing with the 
installation procedure. 


The system console must also be connected. If you are connecting the system console 
via an HP 27128A ASI Card (Asynchronous Serial Interface Card), the card must be 
installed such that its select code is zero (0). Refer to the computer’s installation manual 
to learn how to install the interface card and determine its select code. Before installing 
the card, locate the set of eight switches on the ASI Card. Set the eight switches on the 
ASI Card as shown in Table 2-1. 
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Table 2-1. ASI Card Settings 


Switch 

Value 

Meaning 

1 

open 

Not used 

2 

open 

Indicates a direct connec¬ 
tion 

3 

closed 

parity 

4 

closed 

Character length is 7 bits 

5 

open 


6 

open 

Switches 5-8 set baud rate 
to 9600 

7 

open 


8 

closed 



Alternately, an HP27130A Asynchronous 8-channel MUX card or an HP27140A 6- 
channel modem MUX card may be used when connecting to the system console. It 
must be installed such that its select code is zero (0). The terminal’s interface cable 
must be connected to channel zero (0) of the Multiplex Interface. 

Next the terminal must be configured so that it can ‘‘talk” to HP-UX. The manual sup¬ 
plied with the terminal describes how to use the function keys to configure the terminal. 
First, press the appropriate keys or switches for terminal configuration; select the hard¬ 
wired default values. If necessary, alter the appropriate fields such that the terminal’s 
configuration parameters have the indicated values: 


LocalEcho: 

OFF 

Bits/Character: 7 

CapsLock: 

OFF 

Parity: none 

InhHndShk(G): 

YES 

RecvPace: Xon/Xoff 

Inh DC2(H): 

YES 

Full Duplex 

Baud: 

9600 

EnqAck: YES 


After the system is installed and running, you may change the configuration parameters 
to suit your own needs. Refer to Chapter 5, the section “Adding/Moving Peripheral 
Devices”, the subsection “Terminals and Modems”, for a discussion of terminal and 
datacomm parameters. The above shows what HP-UX expects while installing, but you 
may need different datacomm settings. 

Now, verify that the computer, the CS/80 disk drive, the HP-IB interface card and 
console are installed and operating properly by following the instructions supplied in the 
computer’s Installation Guide. 
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Installation 

Load the First “Installation” Tape 

Now power up the CS/80 disk drive and remove the tape labeled ‘'Series 500 HP-UX In¬ 
stallation, Tape 1” from its case. Locate the write-protect mechanism (labeled “SAFE”) 
on the top, rear, left-hand corner of the cartridge tape as shown in Figure 2-1. The arrow 
on the protect screw should point away from the word SAFE. If it does not, use a coin 
or screwdriver to turn the protect screw such that the arrow points away from the word 
SAFE. Your system must be able to write to the tape during installation. 



Figure 2-1, The CS/80 Cartridge Tape SAFE Mechanism 


Holding the tape with the SAFE label in the rear left hand corner, insert the utilities 
tape into the tape drive door and push until it clicks into place. Only the BUSY indicator 
should now be lit. The tape drive will begin a cartridge tape conditioning sequence that 
takes approximately two minutes. 


Installing HP-UX 17 



Begin the Installation 

Turn the power to your Series 500 computer on. When the boot ROM assumes control 
of your system, it will attempt to boot an operating system. Since the loader finds 
removable media first, the installation program on the first installation tape will be 
loaded into memory if your machine is properly configured. You will see a series of 
messages similar to the following on your console: 

f ^ 

Loader Rev B 
Testing Memory... 

Searching for System... 

Series 500 HP-UX Installation Utility 


Load done. 


Note 

If any other message is displayed, refer to the appendix entitled 
“System Loader Messages” in the computer’s installation manual. 
If no message is displayed, verify the operation of the computer and 
its peripherals by performing the tests described in the computer’s 
installation manual. 


It will take a couple of minutes for the installation program to load. Note that the 
menus from other versions of the installation utility may be somewhat different from 
those shown in Figure 2-2. The procedure will be the same. 
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HP-UX INSTALLATION UTILITY — DEVICE MENU 
*♦♦♦********♦**♦♦:♦:**♦**♦♦*****♦♦♦*****♦**♦****♦*♦*♦*♦****♦♦♦♦** 

Source Device Destination Device 


Maj or Number 1 
Select Code 5 
Bus Address 0 
Unit Number 1 
Volume Number 0 


Device File /dev/update.src 


Maj or Number 1 
Select Code 5 
Bus A4dress 0 
Unit Number 0 
Volume Number 0 
Device File /dev/hd 


Choice Description 

[Return]: CONTINUE Installation Process 

"e": EXIT Installation Process 

"s": Change the SOURCE Device 

"d": Change the DESTINATION Device 

Please enter choice » 


Figure 2-2. Device Menu 

Once you have begun the installation process, the above screen menu will appear, showing 
you the default source (tape drive) and destination (disk drive) addresses. You may do 
any one of four things at this point. 

• You may decide to continue with the installation process, using the device param¬ 
eters as shown. However it is possible that the parameters shown will not exactly 
match your current machine configuration, so double check once more. If you are 
sure, type i Return | to continue (be careful not to type in several returns). 

• You may exit the installation process by typing | e | and hitting | Return | . This will 
end the program and rewind the first installation tape. 

Installing Series 500 HP-UX will result in the complete initialization of the specified 
disk root volume. If you have anything you wish to keep stored on the destination 
CS/80 device, or if you wish to change your hardware configuration, type in [T] 
followed by a | Return | . 
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• You may change the address for the source device by typing [Tl and hitting | Return | . 
If you wish to change a value, type in the new value followed by a | Return | ; otherwise 
the old value will be retained. Once you decide to change the address for the source 
device, you will be prompted for each of the following values: 

a. The source major number. This will usually be 1. 

b. The source select code. The range for the select code is 0 through 23, inclusive. 
These are the address switches set on your interface card. 

c. The source bus address. The range for the bus address is 0 through 7, inclu¬ 
sive. The switch settings on the device determine the bus address. 

d. The source unit number. The range for the source unit number is 0 or 1. 

e. The source volume number. This will always be 0 unless you have configured 
your disk to contain multi-volumes. 

• You may change the address for the destination device by typing | d | and hitting 
I Return | . If you wish to change a value, type in the new value followed by a | Return | ; 
otherwise the old value will be retained. Once you decide to change the address for 
the destination device, you will be prompted for each of the values discussed in the 
above option. 

When the addresses for the source and destination devices are correct on the device 
menu, hit | Return | to continue installing HP-UX on your Series 500. 
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}ie:t(3ic9tc^^:te9(e3f::(c3te94ci|e:|(9|e:f;9tc:(c:tc9|c%>(e3f(a|c3l(*3le%:(t**3|c:(e:(c:tc3i(%:4c***a|e](c:4(:t::|c:4e3|c:tc*3|c3(c4:* 

HP-UX INSTALLATION UTILITY -- BOOT AREA MENU 


DISC INTERLEAVE FACTOR: 
DISC BOOT AREA SIZE: 
DISC BLOCK SIZE: 


1100000 

1024 


Choice 


Description 


[Return]: CONTINUE Installation Process 

"e”: EXIT Installation Process 

"i": Change Disk INTERLEAVE Factor 

"a": Change Disk Boot AREA Size 

"b": Change Disk BLOCK Size 


Please enter choice » 


Figure 2-3. Boot Area Menu 

Now that you have determined the source and destination device addresses, you will see 
the boot area menu as shown in Figure 2-3. This menu displays the optimal interleaving 
factor, boot area size and optimal block factor for the root disk (destination device). At 
this point you have five options: 

• You may decide that the values shown are correct, and continue the installation 
process by hitting | Return | . 

• You may exit the installation process by typing | e | and hitting | Return | . This will 
end the program and rewind the first installation tape. 

• You may want to use a different interleaving factor than the one shown — type [T] 
and hit | Return | to change the value. When prompted type in the new value followed 
by a I Return | ; if you do not type in a value the default will remain unchanged. 
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• You may decide to use a different boot area size for your system. The boot area is 
that part of the disk which contains the kernel, device drivers and optional products 
such as LAN code. The kernel requires about about 600 Kbytes, with LAN requiring 
an additional 300 Kbytes. To install certain drivers, software updates and optional 
products you will want to leave additional space in your boot area. The only way 
to make your boot area larger is to re-initialize your disk and re-install HP-UX, so 
the recommended boot area size is 1 100 000 bytes (1.1 Mbytes). 

To change the boot area size, type | a | and hit | Return | . You will be prompted for 
a new value — if you wish to change the size, type in the new value followed by a 
I Return | . Otherwise just hit | Return | . 

• You may want to change the block size for the destination from that shown. This 
is the smallest unit in bytes by which you can segment your disk. Type | b | and 
hit I Return | to change the value shown. Enter the new value followed by a | Return | 
to enter the new value. 
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HP-UX INSTALLATION UTILITY — INSTALL MENU 

:(c9|c9|c3(e9|c4;9|e^^9|c4;:te9|c9|c4;9lc9|e3|e3ie3ie)|e*3|(^3(e3|c*9tc3ie3(c:)e})c3(e:f(:^)|e4:9)ej)c:te3|c:(e9|c:(c:(c}(c:<i::|c3|e:(e:tea|e 

DESTINATION DEVICE 


Maj or Number 1 
Select Code 5 
Bus Address 0 
Unit Number 0 
Volume Number 0 


Choice Description 

"b": BEGIN Initialization and Installation 

"e": EXIT Installation Process 

Please enter choice >> 


V 


J 


Figure 2-4. Installation Menu 

By successfully completing all of the preceeding steps, you should be at the menu shown 
in Figure 2-4. The destination device for the installation procedure should be shown 
along with the proper address. At this point you may decide to abort the installation 
process by typing | e | and hitting | Return | , or to begin the initialization of the root disk 
and the installation of HP-UX by typing | b | and hitting | Return | . 

If you decided to begin the initialization/installation process, the following prompt will 
appear at the bottom of your screen: 

WARNING !!!!!! Completion of Install will RE-INITIALIZE Destination Device! 

Do you want to proceed? » 
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The only way to install HP-UX is to type m and hit | Return | . Any other response will 
cause the installation process to go back to the above menu, where you may either begin 
or exit the installation. Do not cycle power during initialization. If you think that any of 
the parameters you entered on previous menus are wrong, or if you do not wish to erase 
any information on the destination disk, type Ffri and hit | Return~| to get to the above 
menu, then type | e | and hit | Return | to exit the installation process. 


CAUTION 

Do not switch off power to either the computer or CS/80 device 
during disk initialization. Terminating the initialization process 
by turning power off may seriously corrupt the disk medium. 


Table 2-2 shows the typical initialization times (it varies with different interleave factors) 
for the CS/80 disks supported by Series 500 HP-UX: 


Table 2-2. Initialization Time for CS/80 Disks 


CS/80 Disk 

Size 

Initialization 

Time 

HP 7908P 

16.6 Mb 

9 minutes 

HP 7911P 

28.1 Mb 

4 minutes 

HP 7912P 

65.6 Mb 

10 minutes 

HP 7914P/TD 

132.1 Mb 

14 minutes 

HP 7933/7935 

404 Mb 

49 minutes 

HP 7945 

55 Mb 

20 minutes 
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Following disk initialization, the HP-UX installation process will install a full kernel 
without optional segments (e.g., unused device drivers will not be installed) and a subset 
of commands onto the destination disk. A sequence of screens similar to the following will 
be generated. It takes the installation process about 45 minutes to load the information 
onto the hard disk (in addition to the time it takes to initialize the disk): 


***J»C****J|C*******3|CJ|C3|C3|C ****♦*****♦*♦♦♦************♦♦ ♦*:«£♦♦♦ 

HP-UX INSTALLATION UTILITY (Rev x.x) -- EXECUTION TRACE 

Sdfiniting destination; OK. 

Rootmarking destination: OK. 

Mounting destination; OK. 

Making directory; /bin 

Making directory: /usr 

Making directory; /usr/bin 

Making directory: /etc 

Making directory: /etc/sslibs 

Making directory; /dev 

Making directory: /tmp 

Making directory: /etc/file sets 

Building boot area: OK. 

Copying /bin/cpio: OK. 

Copying /bin/mkdir: OK. 

Copying /bin/sh: OK. 


Figure 2-5. Execution Trace Screen 
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The screen now clears and a screen similar to Figure 2-6 appears: 


♦ ♦♦♦♦♦♦s|e**s|es|e****s|cjJC3(t3|c**:4e***s|«*****j|C5|c + *** + ***3|e***5|c** + *3|<:*** 

HP-UX INSTALLATION UTILITY (Rev x.x) -- EXECUTION TRACE 

Copying /bin/pwd: OK. 

Copying /usr/bin/lifcp: OK. 

Copying /usr/bin/tcio: OK. 

Copying /etc/init2: OK. 

Copying /etc/update: OK. 

Copying /etc/sysrm: OK. 

Copying /system.type: OK. 

Copying /etc/sslib: OK. 

Copying /etc/rootmark: OK. 

Copying /etc/oscp: OK. 

Copying device file: /dev/console. 

Linking console to syscon and systty. 

Copying device file: /dev/null. 

Copying device file: /dev/tty. 

Copying device file: /dev/xxx. 


V_ 

Figure 2-6. Execution Trace Screen 


26 Installing HP-UX 





The screen now clears and the information in Figure 2-7 appears. 






HP-UX INSTALLATION UTILITY (Rev x.x) — EXECUTION TRACE 

Marking tape as not loadable and not rootable 
80 that can reboot from destination. 

Rebooting the system, the tape will be unloaded after the reboot. 


Figure 2-7. Execution Trace Screen 

Now the system reboots. Do not try to unload the tape and do not turn off power to 
the cpu, tape drive, or destination disk drive! Once the system has rebooted, you will 
get a screen similar to that shown in Figure 2-8. 

r ^ 


***************** 

HP-UX INSTALLATION UTILITY (Rev x.x) -- EXECUTION TRACE 

:4cs|ej|ei|csf: + + + 3|e + 5jej|e*5|c**5|c3|c3|cs|es|c*s|e****j|e**3|c************************ 

Unloading tape #1, when busy light remains off remove the tape. 

Figure 2-8. Unload Tape Screen 

After an approximately two-minute pause, you will see the following: 

Please insert tape #2 in source device. 

When BUSY light remains off, press [Return]. 

When you see the message to insert tape #2, put the tape labelled “Series 500 HP-UX 
Installation Tape 2” in the tape drive. Wait for the conditioning sequence to finish before 
continuing with the installation process. On some cartridge tape drives, the busy light 
will go on when the tape is inserted, stay on for a minute or so, go OFF for several 
seconds, and then come on again while the conditioning sequence is completed. Wait for 
the busy light to remain off for 5 or 6 seconds before hitting | Return | . 

When you hit [Return | the process takes about one minute to read information from the 
tape. It then displays a menu similar to that shown in Figure 2-9. 


Installing HP-UX 27 



/• \ 

**♦**»(********* ***************** 

HP“UX INSTALLATION UTILITY (Rev x.x) -- EXECOTION TRACE 

*****34e**:4c:t;4;:K:C*)|e3|e:^^9|e)|e**:(e*:ie:^:(e**:(e:i(:4c:)e:tc:tc**************:4e4:**** 


Choice 


Description 


II 

II 


a": 
c" : 


Process ALL File Sets 
Process CORE File Sets 


Please enter choice » 




J 


Figure 2-9. Process File Set Screen 

HP-UX installation tapes come in two forms depending upon the product ordered. 

• If the tapes contain only HP-U,X these two choices are equivalent; they both cause 
everything on the tape to be loaded onto the destination disk. 

• If the tapes contain a bundled product (one that contains HP-UX and several 
optional products as shown on the tape label), choosing the “a” option loads ev¬ 
erything, choosing the “c” option loads only HP-UX. If you choose the “c” option 
any of the other products can be loaded later using the update utility (see “Up¬ 
dating HP-UX and Installing Optional Products” in the “Toolbox” chapter of this 
manual). 
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Once you have chosen one of these options, the installation process will load the file sets 
(collections of related files) for the selected products. As each file set is loaded onto the 
root disk, messages of the form: 

Loading files from "fileset name'' 

will be printed, followed by the name of each file in that file set. Bundled products may 
consist of more than two tapes. If your system has more than two tapes, the installation 
process will indicate when to insert the third tape. Once all file sets have been loaded 
the tape will unload and the system will reboot. (This will take approximately an hour 
for only HP>UX and about an hour and a half for bundled products.) 

Remove the tape from the tape drive and save the installation tapes in a safe place away 
from harsh environments. By leaving a data cartridge near a large motor or other EMF 
emitting device, you will risk loosing the integrity of your data. 

The system now reboots and you will see a login prompt. There are several logins shipped 
with your system. You should login now as the root user, assign a password to root, and 
perform the system administrative tasks described on the following pages. 

If you wish to shut down your system now (or any time), login as the root user and 
execute the shutdown -h command. When you see the “halted” message, you can turn 
your computer off. Never simply turn your computer off without first executing the 
shutdown or reboot command. 


Note 

Now that your system is installed, you have the ability to modify 
and customize the system. However, if you have purchased soft¬ 
ware support services from Hewlett-Packard, only limited changes 
can be made without voiding your agreement. Consult your sup¬ 
port plan or an HP System Engineer regarding intended changes. 


You may make certain modifications suggested in this manual with¬ 
out concern for voiding your agreement. Specifically, all the files 
listed in the “Changing the HP-UX Environment Files” and the 
“Controlling Disk Use” sections of Chapter 5 may be modified 
within reason. 
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Using Your System 

HP-UX is now installed. You still have many tasks to complete before you can use the 
system (particularly a multi-user system). These tasks include protecting your system, 
setting the system clock, and many other system administration tasks. 

Setting Minimum Protections 

Some of the system’s protections are not set up when you first install your HP-UX system. 
The most important of these is that the user root has no password. This means that 
anyone with access to a system terminal can login as root (also called the “super-user”). 
The super-user can execute critical system commands not accessible by regular users. 
By definition, the super-user is potentially dangerous to the system. 


Note 

Do not execute any commands — except those specified in this 
section — while logged in as the super-user (the user with the user 
name, root) until you are very familiar with the system. Other¬ 
wise, you may inadvertently damage the operating system. While 
getting familiar with the system, log in with some other user name 
you have created. 


Setting the Password for Root 

To protect your system, log in as the user root and assign a password to the root user 
by typing: 

passwd 

The system will prompt you for a password. Enter at least 7 characters and/or digits and 
hit I Return | . Note that control characters like those generated by the | Back space | key are 
accepted but sometimes difficult to remember. The password you enter is not displayed 
on the console. The system then prompts you to re-enter the password to confirm the 
password. Do so and, if the two entries match, the program accepts the new password. 
If the two entries do not match, you will be prompted to enter a password twice again. 
The user root will now have to enter that password to login to the system. 

Write down the password you assigned (in a secure place); if it is lost or forgotten, no 
one can log in as the super-user. If the super-user password is lost, the system will have 
to be re-installed (which will destroy any existing files on the system). If this happens, 
call your local HP sales office or the Response Center for assistance. 
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An Unattended System Console 

One other protection item deserves mention: depending on the perceived need for security 
at your installation, use discretion about leaving a system console unattended while 
logged in as the root user as this defeats the password protection. Remember, any user 
logged in with the name root can execute any HP-UX command — a situation possibly 
hazardous to the integrity of your system. 

Setting the System Clock 

Check to see if the system clock is set correctly. Enter: 


date 


The time displayed is in the format of a twenty-four hour clock (for example, 2:00 pm is 
14:00). If the time displayed is not correct, you need to first set the correct time zone 
and then set the system clock. 

As shipped to you, the system is set up to run in the Mountain Time Zone. To temporarily 
change the time zone to your time zone, type two entries of the following form: 

TZ=XXXHYYY 
export TZ 


where XXX and YYY are three letter representations of the standard and daylight time zones 
for your area and H represents the difference between current local time and Greenwich 
Mean Time, in hours. The export TZ line will remain the same regardless of the time 
zone. For example, in Denver, Colorado you would enter the following: 

TZ=MST7MDT 
export TZ 


where MST stands for Mountain Standard Time and MDT stands for Mountain Daylight 
Time. Here are some other examples: 

• In the Eastern time zone, use: TZ=EST5EDT 

• In the Central time zone, use: TZ=CST6CDT 

• In the Pacific time zone, use: TZ=PST8PDT 


Until you change the TZ variable in the file /etc/profile (described in the section “Set¬ 
ting the System Clock” in the “System Administrator’s Toolbox” chapter), you will need 
to set the time zone as described here each time the computer is powered up. 
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Now that the time zone is set, you can set the correct time and date (using the date 
command) by typing an entry of the form: 

date MMddhhmmfyy} 

MM a two-digit integer representing the month. For example, 03 represents March. 

dd a two-digit integer representing the day of the month. For example, 02 represents 

the second day of the month. 

hh a two-digit integer specifying the current hour in terms of a twenty-four hour 
clock. For example, 03 specifies 3:00 am and 14 specifies 2:00 pm. 

mm a two-digit integer specifying the number of minutes past the stated hour. For 
example, 04 specifies four minutes past the hour. 

{yy} an optional two-digit integer specifying the last two digits of the current year. For 
example, 84 specifies 1984 as the current year. This parameter may be omitted if 
the year is already correct. 

When date is executed it echoes the time and date on your screen. If the time and date 
are not correct, repeat the above procedure. Note that you must be the super-user to 
change the date. 

Log out by holding the | Ctrl | key depressed as you press the | d | key. Alternatively, 
typing 

exit 

will also log you off the system. A few seconds after you log off, the login: prompt will 
reappear. 
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System Administrator Tasks 

As the system administrator you must perform many tasks to maintain your system. 
Here are a few tasks you may wish to do now: 

Check for Bugs 

If you haven’t already done so, check the Read Me First document for known bugs. 
Follow^ the instructions in the “Bugs” section of the document. 

Read the Files in the /etc/newconfig/UpdateJnfo Directory 

The files in /etc/newconfig/Update_info contain important information about your sys¬ 
tem. 

Change Device File Naming Conventions 

Previous versions of HP-UX have a different device file naming convention than the 
current standard. This version supports both the old naming convention and the new. 
Hewlett-Packard has supplied you with a script file to convert your device files from the 
old convention to the new convention. Refer to Chapter 5, the section “New Device 
File Naming Conventions” for a description of the script and a discussion of naming 
conventions. 

Add Peripheral Devices 

You will want to install a printer (and probably configure the LP spooler if you have 
several users), install terminals for your users, and possibly install other hardware such 
as plotters and additional disk drives. 

In addition to connecting the hardware to your computer, you must configure your system 
to talk to the hardware. The procedure to do this is in the “Toolbox” chapter, the section 
“Adding/Moving Peripheral Devices”. 

Modify System Files 

You probably need to change the /etc/motd, /etc/profile, and /etc/rc files to fit your 
installation’s requirements. Refer to the “Toolbox” chapter for guidelines. 
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Add Users 

Each user on your system should have a unique login name. In addition, you will want 
to have your own login other that the root login. 

As shipped to you, the HP-UX system is set up to allow any of several users to log in. 
(This is true even for single-user systems where only one user can be on the system at 
time.) Two of the user names are of particular interest: root and guest. 

The root login is very powerful and is potentially dangerous to your system. Until you 
are familiar with HP-UX and understand its operation, you should avoid logging in as 
root for the reasons previously discussed. 

The guest login is restricted and can be used for people who need temporary access to 
the system. 

The procedure to add new users is in the “Toolbox” chapter. 

Backup Your System 

Once your system is installed and you have completed the above configuration tasks, you 
should make a full (archive) backup of the system. The backup procedure and concepts 
are described in the “Toolbox” chapter. 

Create a Recovery System 

A recovery system is a small working version of HP-UX. If your system becomes so 
corrupt that it won’t boot, you can use a combination of your recovery system and your 
backups to re-create your system. If you do not have a recovery system you may need 
to re-install HP-UX. 

The procedure to create a recovery system is described in the “Toolbox” chapter. 
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Moving On 

Now that your system is successfully installed and a few preliminary tasks are done, here 
are a few guidelines for learning more about HP-UX. 

HP-UX is a large and somewhat complex operating system, so time invested in learning 
the system can be substantial. This time, however, is well spent; the more you know 
about the system’s features, the less work you will do in the long run as the system 
administrator. The following manuals will get you started: 

• HP-UX Documentation Roadmap 

This pamphlet lists the manuals in your documentation set, and shows some key 
points from each manual. You can also use this pamphlet to get an introduction to 
major tasks, and to head in the right direction if you have a general topic. 

• The off-the-shelf UNIX tutorial supplied with your HP-UX system. 

Try the examples on your system as you read. While gaining familiarity with the 
system, do not log in as the user root. 

• HP-UX Reference 

Read the introduction to the HP- UX Reference manual and to familiarize yourself 
with using the “permuted index” section of that manual. As mentioned in the 
“Conventions Used in this Manual” section of chapter 1, the permuted index is 
useful for finding entries that are listed under similar related entries. 

• HP-UX System Administrator Manual 

It is assumed that you have already read chapter 1 (“Getting Started”) of this 
manual and the terminology at the beginning of this chapter. 

Read chapter 3 (“Concepts”) and chapter 4 (“System Startup and Shutdown”) in 
this manual. These chapters will give you a good understanding of how the system 
operates. 
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Installation Troubleshooting Hints 

The following should help to troubleshoot problems that occasionally occur during the 
installation process. 

Problems Initializing the Destination Device 

If the destination device (hard disk) initialization fails, you will see a menu similar to 
that shown in Figure 2-10. 


HP-UX INSTALLATION UTILITY (Rev x.x) -- EXECUTION TRACE 
+ *************************** ******************** 
Sdfinit*ing destination: FAILURE: errinfo = 236. 

DESTINATION DEVICE 


Maj or Number 
Select Code 
Bus Address 
Unit Number 
Volume Number 


Choice 


Description 

Change the DESTINATION device. 
EXIT Installation Process 


INITIALIZATION OF DESTINATION DEVICE FAILED 
Please enter choice >> 



Figure 2-10. Initialization Error Screen 
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This could be caused by incorrectly specifying the address of the destination device, 
forgetting to power on the destination device, or incorrectly installing the destination 
device. Choosing the “d” option allows you to change the destination device address. 
After changing the destination device address, the installation process will start the 
initialization process again. 

If you are not sure that the hardware was installed correctly then choose the “e” option, 
turn off the power to your computer, check the hardware installation, and then restart 
the installation process. If this condition persists and you are sure that you are using 
the correct device address, contact your local HP sales office or Response Center. 

Problems While Loading From the Installation Tapes 

The following errors (and their common causes) can occur during the installation process; 
they will appear in either the menu shown in Figure 2-11 or the menu shown in Figure 
2-12. 


ERROR: CANNOT FIND CONTENTS ON xxxx 

Tape number 1 was loaded when tape number 2 or 3 was expected, or | Return | was pressed 
before the tape conditioning sequence was complete. 

ERROR: CANNOT FIND CORE PRODUCT ON xxxx 

Tape number 2 was not loaded when requested. 

ERROR: CANNOT PROCESS DEPENDENCY xxxx 

An error occurred while trying to read from the tape, the most likely cause is a dirty 
tape head. 

ERROR: CANNOT PROCESS FILESET xxxx 

An error occurred while trying to read from the tape, the most likely cause is a dirty 
tape head. 


Installing HP-UX 37 



:|c*:(c9(cHc********3<e3<(********3)<:3(t***3(e***34c34c***:»:****’4c*** ********* 


HP-UX INSTALLATION UTILITY (Rev x.x) -- EXECOTION TRACE 
******************************************************* 

Choice Description 

"e": EXIT Installation Process 

"s": SWITCH tapes 


ERROR MESSAGE 

I Please enter choice >> I 

Figure 2-11. Error Screen 

In almost all cases the screen shown in Figure 2-11 results from loading the wrong tape 
or not waiting for the tape conditioning sequence to complete. You should choose the 
“s” option which results in the following: 

Unloading tape #2, when busy light remains off remove it. 

(about a 2-minute pause) 

Please insert tape #2 in source device 
When BUSY light remains off, press [Return]. 

Remove the tape and wait for the message asking you to insert it. Then insert the correct 
tape, wait for the conditioning process to complete (to be sure the process is complete 
— wait at least five or six seconds once the busy light remains off), and hit I Return ! . If 
the condition occurs again, be sure that you are indeed loading the correct tape. If the 
condition persists, try cleaning the tape head before loading the tape. In the rare case 
that this doesn’t help, contact your local HP sales office or Response Center. 

Choosing the “e” option causes the install process to terminate. If enough of HP-UX 
has loaded, the system will reboot and come up in init run-level s. If this occurs, you 
can try using update, possibly with a new tape drive or new tapes, to reload HP-UX (to 
ensure that everything gets on your system) or to load missing optional products. You 
will select the same product numbers in update that you selected in installation. If the 
system is unable to reboot, you will need to restart the install process, possibly with a 
different tape drive or tapes. 
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HP-UX INSTALLATION UTILITY (Rev x.x) -- EXECUTION TRACE 

*****3)C************************************************* 


Choice Description 

"e": EXIT Installation Process 

"r": RETRY last operation 

"c"; CONTINUE with Next Fileset 

ERROR MESSAGE 
Please enter choice >> 


Figure 2-12. Error Screen 

The screen shown in Figure 2-12 is normally associated with a read failure from the tape 
drive, which could be temporary, the result of dirty tape heads, a problem with the tape, 
or a problem with the tape drive. 

If the failure occurred while loading one of the file sets that makes up HP-UX (versus an 
optional product), you will not get the ‘^CONTINUE” option. In this case, choose the 
“RETRY” option (hit \~r\ ). If the retry is not successful, it could be due to a problem 
with the tape drive. One possibility is a dirty tape head. Unload the tape, clean the 
head, reload the tape, wait for the conditioning process to complete, and select the “r” 
option. If this condition persists (and you are loading a file set in HP-UX, indicated by 
the lack of a continue option), contact your local HP sales office or Response Center. 

If the failure occurred while loading one of the file sets in an optional product, try the 
above steps. If the condition persists, choose the “c” option to go on. The particular 
optional product may not be usable, but the installation process should be able to com¬ 
plete and you should have a usable system. If loading file sets for optional products 
continues to fail, choose the “e” option; the installation process should be able to reboot 
your system and come up in init run-level s as it normally does. You can then try using 
update (see “Updating HP-UX and Optional Products” in the “Toolbox” chapter of this 
manual) to load the optional products, possibly after having your tape drive serviced 
or using another tape drive. If update is unable to load the optional products from the 
tape, contact your local HP sales office or Response Center. 
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Notes 
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Concepts 




This section discusses several essential concepts needed to manage an HP-UX system. 
It is not necessary to initially understand all of these concepts in depth; however, you 
should at least be familiar with the terms. 


Processes 

A process is an environment in which a program executes. It includes the program’s code 
and data, the status of open files, the value of all variables, and the current directory. 
Each process is associated with a unique integer value (called the process ID) which is 
used to identify the process. 

Process Creation 

(Parent and Child Processes) 

A process consists of a single executing program at any given time. However, a process 
can create another process to: 

• concurrently execute another program. 

• execute another program and wait for its completion. 

A new process is created when a program executes either the fork or the vfork system 
call. The terms parent process and child process refer to the original process and the 
process which it created, respectively. 

Using fork 

When a child is created with a fork system call, nearly all code and data (including 
virtual code and data) is copied from the parent to the child. Only shared code is not 
copied (the child process uses the same shared code as the parent process instead of 
creating a separate copy for itself). Thus, the child process is nearly identical to the 
parent process (with the exception of its process ID); it has exact copies of the parent’s 
code, data and current variable values. 
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When the fork system call is executed, the system must have enough free memory to 
duplicate the parent process or the call to fork fails. Once the child process is created, 
both processes begin execution from the completion of the call to fork (at the program 
statement immediately following the call to fork). 

The fork system call returns the actual process ID of the child (a non-zero value) to 
the parent process, while the identical call in the child’s copy of the code always returns 
zero. Since the process IDs returned by the fork system calls are distinguishable, each 
process can determine whether it is the parent process or the child process. 

For example, suppose that a process consists of a program that tests the life of car 
batteries. The program has read 1000 data values from a voltmeter and is ready to print 
and plot the data. The program could have been written to do one task completely (such 
as printing the data) and then perform the other task. However, the programmer has 
included a fork system call in his program at a location after the data has been read. 

When the program completes the statement containing the fork system call, two nearly 
identical processes exist. Each process examines the value returned by its fork system 
call to determine whether it is the child process or the parent process. Following the 
fork statement is a conditional branch statement that states: “If the process is the child 
process, it should print the data. If the process is the parent process, it should plot 
the data”. Because of the inclusion of the fork statements and the conditional branch 
statement, both printing and plotting are done simultaneously. And because each process 
has its own copy of the test data, each can modify the data without affecting the other 
process. 

Using exec 

One modification which often follows the fork system call, is to exec another program, 
exec is a system call which overlays a separate code segment on top of already existing 
process code. In this manner a parent process is able to create a new process using fork, 
and subsequently execute an entirely different program via exec. 

As an example, let’s suppose we are writing a text editor. We would like to let the user 
of our editor pause and list directories on the system say before choosing a file to 
edit. One way of doing this would be to fork a different process, and then immediately 
exec the program is. Let’s look next at the vfork system call for a more efficient way of 
doing this. 
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Using vfork 

Copying a parent process’s code and data to a child process can be time consuming when 
a large program or a large amount of data is involved. The vfork system call provides an 
alternate way to create a new process in situations where generating a separate copy of 
the parent process’s code and data is not necessary, vfork differs from fork in that the 
child process borrows the parent process’s memory and thread of control until the child 
executes either an exec or exit system call, or it terminates abnormally^ The parent 
process is suspended while the child uses its resources. 

In situations where the child process is simply going to call exec, the parent’s code and 
data is not required by the child. If fork is used to create the child process, time is 
wasted copying the unneeded code and data. Depending on the size of the parent’s 
code and data space, using vfork instead of fork can result in a significant performance 
improvement. 

Like fork, vfork returns the actual process ID of the child process to the parent process 
and returns a zero to the child. 

Process Termination 

A process terminates when: 

• the program that is executing in the process successfully completes. 

• the process intentionally terminates itself by calling the exit or _exit system call. 

• the process receives from any process a signal for which the default action is taken. 

When a process “dies” (terminates), all open files associated with the process are closed. 
System resources associated with the process are deallocated. 

Process Groups 

A process group is a set of related processes, such as a parent process, its child processes 
and its children’s child processes. 

A process group is established when a process calls the setpgrp system call. The calling 
process becomes the process group leader; it and all of its descendants (such as its child 
processes and grandchild processes) are members of only that process group. Process 
group membership is inherited by a child process. Each active member of the process 
group is identified by the process ID of the process group leader. The init process is 
the parent process of all processes. It initially sets up process groups as it executes 
commands from the command field of /etc/inittab. 
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A signal sent to a process may also be sent to all other members of its process group. 
Typically, process groups are used to ensure that when an affiliated process group leader 
terminates, all members of its process group also terminate. 

Terminal Affiliation 

Process groups and process group leaders have significance in that a process group leader 
can become “affiliated” with a terminal. All standard input, standard output and stan¬ 
dard error generated by process group members is, by default, directed to the affiliated 
terminal (unless redirected). Affiliation is caused by an unaffiliated process group leader 
opening an unaffiliated terminal. Only a process group leader can become affiliated. At 
the time of affiliation, the process group leader cannot be affiliated with any other ter¬ 
minal and the terminal cannot be affiliated with any other process group. The terminal 
sends signals to the members of its affiliated process group in response to the interrupt 
character (DEL), QUIT ( | Ctrl 11 / | ), the | Break ! key or a modem hangup signal. 

A child process inherits terminal affiliation when it is created. Thus, if an unaffiliated 
process group leader creates a child process, the child process is unaffiliated, even if the 
parent process becomes affiliated later. 

Open Files in a Process 

For a process to access files, it must first open them. HP-UX limits the number of files 
that one process can have open to 60. Three of these are usually opened automatically 
when a process is created: standard input (stdin), standard output (stdout), and stan¬ 
dard error (stderr). When a process terminates, the system closes any files that this 
process has open. 
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IDs 

As previously mentioned, each process is assigned a process ID (a unique integer value) 
which identifies that process. The process also has associated with it a real user ID, a 
real group ID, an effective user ID, and an effective group ID. 

A real user ID is a integer value which identifies the owner of the process. Similarly, a 
real group ID is an integer value which identifies the group to which the user belongs. 
The real group ID is a unique integer identifier that is shared by all members of a group. 
It is used to enable members of the same group to share files without allowing access to 
these files by non-group members. The real user ID and real group ID are specified by 
the file /etc/passwd and are assigned to the user at login. 

Effective user and group IDs allow the process executing a program to appear to be the 
program’s owner for the duration of its execution. The effective user ID and group ID 
are separate entities and can be set individually. The effective IDs are usually identical 
to the user’s corresponding real IDs. However, a program can be protected such that 
when executed, the process’s effective IDs are set equal to the real IDs of the program’s 
owner. The new effective ID values remain in effect until: 

• the process terminates 

• the effective IDs are reset by an “overlaying” process (a process is “overlaid” via 
the exec system call) 

• the effective IDs are reset by a call to the setuid system call or the setgid system 
call 

The primary use of effective IDs is to allow a user to access/modify a data file and/or 
execute a program in a limited manner. When the effective user ID is zero, the user is 
allowed to execute system calls as the super-user (described in the following section). 

For example, suppose that the dean of a university keeps all of his student’s records 
in a file on the system. He wishes to enable a professor to modify a student’s record 
only for that professor’s class (an English professor shouldn’t be allowed to modify a 
student’s grade in physics). The dean first protects the file containing the student’s 
records such that only he may read or write to it. He then writes a program which 
receives the modifications requested by a user, checks to see that the user is allowed to 
make such changes, and then modifies the record if allowed. Finally, the dean protects 
the program such that the effective IDs of the user are set equal to the dean’s real IDs 
when the program is executed. Then when the program accesses the student record file, 
the system allows the program to read from or write to the file because it believes that 
the dean is accessing the file (the effective user and group IDs are that of the dean). 
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The Super-User 

The term super-user describes the system user whose effective user ID equals 0. Users 
with effective user ID equal to 0 are provided with special capabilities by HP-UX (hence 
the name ‘‘super-user”). Many commands and system calls can only be accessed by a 
super-user. Some commands and system calls can be accessed by other users, but have 
some features accessible only by the super-user. A super-user is granted the ability to: 

• execute any command in the system, as long as any execute permission permission 
bit is set in the command file’s mode 

• override any protections placed on user files (except those created and protected 
by other systems, such as the BASIC Language System) 

• modify any system configuration files, add (and remove) users to the system 

• other system functions 

Super-user status should only be granted to those users who have a thorough understand¬ 
ing of the system and have a need for super-user capability. As system administrator, 
you must have super-user capability. 

Some super-user commands and some system calls (those used heavily by the system 
administrator) require the user’s name to be “root” and his real user ID to be zero. As 
shipped, your system has a user name of root with a real user ID of 0. This user is often 
referred to as “the root user”. Log in as this user when acting as system administrator. 
To prevent other users from accessing super-user capabilities, assign a password to “root”. 
Only you and the “back up” system administrator(s) should know this password. 
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File System Implementation 

The Series 500 HP-UX system uses a file system called the Structured Directory Format 
(SDF) file system. This chapter describes the SDF file system. This information should 
aid you when verifying, maintaining and repairing the HP-UX file system(s). 

The files of the SDF file system are stored on a formatted mass storage medium, usually 
a disk. A file is specified by a path name—a series of directory names separated by 
/ characters and terminated with the file name. The actual method in which files are 
stored is explained by the text and diagrams that follow. 

The file system implementation is a concept best explained by example. Suppose that 
you have a file named FILE which contains a list of mailing addresses. When FILE is 
created, the system places its name in a directory. A directory is a special form of an 
HP-UX file. It then associates a unique integer value (in this case, 23) with the file 
name. This integer value (called an i-node value or number) points to a structure called 
an i-node. In turn, the i-node contains a pointer to one or more groups of contiguous 
disk blocks, called extents, in which FILE’S data is actually stored. A pointer in the 
i-node consists of the starting address of the file’s extent(s) and the size of the extent(s). 
This is shown in Figure 3-1. All i-nodes for a file system are kept in a file called the File 
Attributes File. Each disk has a single File Attributes File which describes the contents 
of the disk. 
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File Attributes File 



* The free map may actually occupy more than one i-node. 
* * Actual contents of FILE. 

Figure 3-1, File with a Single Extent 
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From Figure 3-1, you can see that besides an i-node for each file stored on the disk, the 
File Attributes File contains an area called the free map. The free map is an array of 
binary values, one for each block on the disk. If a bit value is 0, the corresponding disk 
block is currently being used for storage. If a bit value is 1, then the corresponding disk 
block is available for storage. 

When a file is created, its contents are placed in one large extent, if possible. If the file 
is later modified and enlarged, the system attempts to place the added information in 
blocks that are contiguous with the existing extent. If there are not enough free blocks 
that are contiguous to the existing extent, the system places the added information in a 
single new extent (if possible); it then adds to the file’s i-node, a pointer to the additional 
extent. The i-node is capable of holding four pointers to the extents which comprise the 
file. If the system finds it necessary to create more than four extents for a file, an extent 
map is automatically added (chained) to the file’s i-node. An extent map is capable of 
holding an additional 13 pointers; there is no limit to the number of extent maps which 
may be added to an i-node. You should note, however, that as the number of extents 
claimed by a file increases, the amount of time required to access the information also 
increases. 

Figure 3-2 shows the structure of the file, FILE (from the previous example) after it 
has been modified several times. When FILE was modified, there were not enough free 
blocks contiguous with the existing extent in which to place the added information. 
Thus, additional extents were created to hold the new information. When the number 
of extents claimed by FILE surpassed four, the system added an extent map to FILE’S 
i-node. 
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File Attributes File 


directories 


i-node number 0 


extents 



* The free map may actually occupy more than one i-node. 
* * Actual contents of FILE. 

Figure 3-2. File with Multiple Extents 
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In HP-UX, it is not unusual to have a single file on a disk which has several file names; 
the file is said to have multiple links. A file has multiple links when the file’s i-node is 
pointed to by two or more directory entries. Each directory entry has its own name for 
the file but all share the same i-node value and thus, the same extents containing the 
file’s data. 

For example, suppose that three users all wish to have the file FILE (from the previous 
examples) in their login directory. Each user creates a link to FILE (via the link or In 
command) from his login directory. From the viewpoint of each of these users, the file 
resides in their login directory. 

A link is removed when a user removes the file from his directory (for example, with the 
rm command). When all links to an i-node have been removed, the disk blocks forming 
the file’s extents are marked “free” in the free map. The file’s i-node and extent maps 
(if it has extent maps) are marked as unused. Note that you cannot link a file across 
different file systems (i.e., different disks). 
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File Attributes File 



* The free map may actually occupy more than one i-node. 
* * Actual contents of FILE. 

Figure 3-3. File with Multiple Links 
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The Volume Header 

Each disk or tape mediurn available to your HP-UX system is called a volume. Each 
volume has a volume header located at block 0 of the volume. The volume header: 

• identifies the volume format (always Structured Directory Format [SDF] for HP-UX 
files on the Series 500). 

• specifies the size in bytes of each disk block. 

• lists the maximum number of disk blocks available on the disk. 

• lists the starting block number of the File Attributes File. 

• lists the size and the starting location of the boot area. 

• contains other system information (as described in fs(4) in the HP-UX Reference 
manual). 

File Format and Compatibility 

The format of the mass storage media on which HP-UX files are stored is Structured 
Directory Format (SDF). This is not necessarily the format for other operating systems 
patterned after the UNIX operating systems. 

If you are using both HP-UX and the BASIC Language System on your computer (sup¬ 
ported on the Model 520 only), you should consider the following compatibility issues: 

• BASIC recognizes many different file types (BDAT, BIN, ASCII, DATA and BCD). 

• To BASIC, all HP-UX files are BDAT files. 

• When BASIC files are copied with HP-UX commands, the file type of the copy is 
always BDAT (regardless of the file’s original type). 

• If a file or directory is used by both BASIC and HP-UX, be careful in assigning 
protections. A file protected in BASIC may not be accessible from HP-UX. Files 
with protection (access restrictions) in HP-UX may not be accessible from BASIC. 

This last issue needs to be examined in more detail. When an HP-UX file is accessed 
from BASIC, the file’s HP-UX mode corresponds to the file protection of a BASIC file. 
The HP-UX file’s read and write permissions for the class of users “other system users” 
(not the file’s owner nor the file’s group) are interpreted as the read and write protections 
of a BASIC file. The file’s execute permission (as specified by its mode in HP-UX) is 
ignored when the file is accessed from BASIC. 

The read, write and execute permissions of an HP-UX directory affect the manner in 
which the directory (and the files it contains) can be accessed from BASIC. The inter¬ 
pretations of the different protections for directories are shown in Table 3-1. 
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Table 3-1. File Protection 


HP-UX Directory Protection 

BASIC Directory Protection 

r — (read permission) allows the user to list 
the contents of the directory. 

w — (write permission) allows the user to add 
and remove files from the directory. 

X — (execute permission) allows the user to 
search the directory. This permission must be 
set in order to access a file below the directory 
in the file system hierarchy. 

R — (read permission) allows the user to list 
the contents of the directory with the BASIC 
CAT statement. 

W — (write permission) allows the user to cre¬ 
ate or delete entries from the directory 

No equivalent BASIC protection. 


For an HP-UX file to be accessed from BASIC, all directories in the file’s path must have 
both the read and execute permissions enabled for “others”. When an HP-UX file or 
directory is examined with the BASIC CAT statement, it is not possible to determine 
whether or not its HP-UX execute permission is enabled. 

Compatibility Tips 

When creating files for use by both the BASIC Language System and HP-UX, assign no 
file protection to the file or to the directories containing the file. This ensures that both 
systems can access the file. 

Use BASIC to back up volumes containing both BASIC Language System files and HP- 
UX files. This preserves the file types of all of the files. 

File Protection 

When each file in the file system is created, it is assigned a set of file protection bits, 
called the mode of the file. The mode determines which users may read from the file, 
write to the file, or execute the program stored in the file. Read, write, and execute 
permissions for a file can be set for the file’s owner, all members of the file’s group (other 
than the file’s owner) and all other system users. The three permissions are mutually 
exclusive—no member of one permission group is included in any other permission group. 
When a file is created, it is associated with an owner and a group ID. These values specify 
which user owns the file and which group has special access capability. 

The default mode of a file is initially determined by the umask command when the file is 
created. The mode may be changed with the chmod command. The mode of the file is 
represented as the binary form of four octal digits as shown in Figure 3-4. The initial 
discussion deals with only the three least significant digits. When the most significant 
digit is not specified, its value is assumed to be zero (0). 
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Each octal digit represents a three-bit binary value: one bit specifies read permission, 
one bit specifies write permission, and one bit specifies execute permission. If the bit 
value is one, then permission is granted for the associated operation. Similarly, if the bit 
value is zero, permission is denied for the associated operation. 

For example, assume a file has a mode, 754 (octal). Octal 754 is equivalent to 111 101 
100 binary. From Figure 3-5, you can see that this grants the owner of the file read, 
write, and execute permission. It grants read and execute permission to all users who 
are members of the file’s group (except the file owner). That is, any user (except the 
file’s owner) whose effective group ID is equal to the ID of the file’s group may read and 
execute the file. It grants read permission to all other system users. The Is command 
represents this mode as rwxr-xr--. 
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Protecting Directories 

Directories, like all files in the HP-UX file system, have a mode. The directory’s mode is 
identical to the mode of an ordinary file. The read, write, and execute permissions have 
a slightly different meaning when applied to a directory. 

• Read permission provides the ability to list the contents of a directory. 

• Write permission provides the ability to add a file to the directory and remove a file 
from the directory. It does not allow a user to modify the contents of the directory 
itself This capability is given to the HP-UX system only. 

• Execute permission provides the ability to search a directory for a file. If execute 
permission is not set for a directory, the files below that directory in the file system 
hierarchy cannot be accessed even if you supply the correct path name for the file. 

Setting Effective User and Group IDs 

In the section discussing effective user and group IDs, you found that a file can be 
protected such that when executed, the process’s effective IDs are set equal to the file 
owner’s IDs. This capability is specified through the most significant digit of the four 
octal file protection mode digits of an executable file (previously discussed). This digit is 
represented by a three-bit binary value. When its most significant bit is 1, the effective 
user ID of the process executing the file is set equal to the user ID of the file’s owner. 
This bit is called the set user ID bit (suid). Similarly, if the middle bit of the most 
significant octal digit is I, then the effective group ID of the process executing the file 
is set equal to the group ID of the file’s group. This bit is called the set group ID bit 
(sgid). 

If the sgid bit is on for an ordinary file, and the file does not have group execute permis¬ 
sion, then the file is in enforcement locking mode. See the section which follows on file 
locking, or lock(2) in the HP-UX Reference. 
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For example, suppose that the file mode is 6754. Octal 6754 is equivalent to 110 111 101 
100 binary. The meaning of the mode is shown in Table 3-2 and Figure 3-6. 

Table 3-2. File Protection Example 2 


Octal 

Digit 

Binary 

form 

Permission 

Meaning 

0 

1 

set user ID 

Effective user ID of the process executing this file is set 
equal to the real user ID of the file’s owner. 

1 

set group ID 

Effective group ID of the process executing this file is 
set equal to the group ID of the file’s group. 

0 

sticky bit 

The sticky bit is discussed in the section that follows. 

7 

1 

read 

File owner may read the file. 

1 

write 

File owner may write to the file. 

1 

execute 

File owner may execute the file. 

5 

1 

read 

Members of the file’s group (other than the file’s owner) 
may read the file. 

0 

write 

Members of the file’s group (other than the file’s owner) 
cannot write to the file. 

1 

execute 

Members of the file’s group (other than the file’s owner) 
may execute the file. 

4 

1 

read 

Any other user may read the contents of the file. 

0 

write 

Other users cannot write to the file. 

0 

execute 

Other users cannot execute the program contained in 
the file. 
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Figure 3-6. File Protection Mode Example 2 
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D = octal digit 
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The Sticky Bit 

Although the sticky bit can be set for all programs, setting the sticky bit affects a 
program only if it is shared (refer to Memory Management Concepts discussed later 
in this chapter). The following discussion assumes that all files marked sticky are also 
shared. 

The least significant bit of the upper octal digit is called the sticky bit. When the sticky 
bit of a program file is set and the program is executed, the code segments of the file are 
loaded into the system partition (discussed with the memory management concepts later 
in this chapter), where they remain until you specify that they are to be removed. All 
users executing the file actually use the copy of the program that resides in the system 
partition. Setting the sticky bit reduces the amount of time needed for a number of users 
to access a program (since the code is transferred from disk only once). However, since 
the contents of the file remains in memory, the amount of memory available for other 
users decreases. 

Once a program is in the system partition (via the sticky bit), it can only be removed 
by changing the file’s mode such that the sticky bit is no longer set. When the file is 
executed again, the system recognizes the new mode and deletes the memory-resident 
copy of the file. 

Only the super-user can set the sticky bit. 

File Sharing and Locking 

In a multi-user, multi-tasking environment such as HP-UX it is often desirable to control 
interaction with files. Many applications share disk files, and the status of information 
contained in them could have serious implications to the user (such as lost or inaccurate 
information). 

For example, imagine we are responsible for maintaining on-line technical reports for 
a myriad of projects, and we have many different people who must have simultaneous 
access to these reports. The content of a given report at a given time could significantly 
affect a company decision, and so we want a way to control how records are accessed. 

One potential problem could arise if one person (let's call him George) adds to or modifies 
information in a report while someone else (Sarah) is working on it. Sarah is unaware 
of changes that George has just made in the report. And once she is done, Sarah 
overwrites the information George added. The result is that we have lost all of George’s 
information, and when Sarah added data she was unaware of information which could 
have been pertinent. 


58 Concepts 



Advisory Locks 

A solution to this common problem of file sharing is called file locking. On your Series 500, 
file locking is done with the lockf system call, and it handles two modes of file integrity. 
Advisory locks are placed on disk resources to inform (warn) other processes desiring to 
access these same resources that they are currently being accessed or potentially being 
modified. Advisory locks are only valuable for cooperating processes which are both 
aw^are of and use file locking. 

In our example, the programs used to access the on-line technical reports could use 
advisory locks. When George begins to work on the FubNibWitz project his program 
could call lockf and set an advisory lock. A few minutes later when Sarah tries to access 
records in the FubNibWitz report, she would get an error message informing her that the 
report is busy. Her program could wait until George is done and then access the report, 
by virtue of doing a call to lockf. 

Locking Activities 

As stated earlier, all file locking is controlled with the lockf system call. There are 
essentially four activities which lockf controls: 

• Testing file accessibility by checking to see if another process is present on a specific 
file record. 

• Attempting to lock a file. If the record is already locked by another process, lockf 
will put the requesting process into a sleep run-level until the record is free again. 

• Testing file accessibility and locking the record if it is free, and returning immedi¬ 
ately if it is not. 

• Unlocking a record previously locked by the requesting process. 

When the locking process either closes the locked file, or terminates, all locks placed by 
that process are removed. For more details on how specific locking activities work on 
HP-UX, see the lockf(2) section of the HP-UX Reference manual. 

Enforcement Mode 

Even if we use advisory locks in our example, Sarah would still be able to overwrite the 
FubNibWitz. She needs some way to insure that no records are written until George 
is done with the report. HP-UX does this with enforcement mode. When a process 
attempts to read or write to a locked record in a file opened in enforcement mode, the 
process will sleep until the record is unlocked. 
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Enforcement mode is enabled by turning the set-group-id bit on (ORing the file mode 
with octal 2000) and clearing the group-execute bit (ANDing the file mode with octal 
7767). For example if we opened a file which normally has its file access mode set to 755, 
an 11 of the file would look something like; 

-rwxr-xr-x 1 George LubHood 0 May 7 16:11 FubNibWitz 

To turn enforcement mode on, we would turn the set-group-id bit on (resulting in 2755) 
and then clear the group-execute bit (resulting in 2745). This could be done from the 
shell with the chmod command, or from a program with the chmod system call, A long 
listing would show: 

-rwxr-sr-x 1 George LubHood 0 May 7 16:11 FubNibWitz 

By now using enforcement mode, George could prevent Sarah from overwriting his 
changes, and Sarah would have the data which George went to all the trouble of adding 
to begin with. 


Warning 

It is possible to cause a system deadlock in enforcement mode. By 
calling the wait or pause system calls immediately after locking a 
record, the locking process could hang one or more processes which 
attempt to access the locked record. 


When attempting to access a command which is locked under enforcement mode, the 
shell will go into a sleep run-level until the command is released. This provides a means 
for one script to control execution of another separate script. Care should be exercised 
when doing this, because as just noted, a system deadlock is possible. 
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Magnetic Tape 

Since computers are sometimes used to process massive amounts of data, there must be 
a way to store large files on-line. Applications such as atmospheric studies, which minute 
by minute record megabytes of information and then sort it out, require cheap media to 
store data on. Even with the advent of larger capacity hard disk drives, they are still 
too small and far too expensive for such purposes. 

Perhaps the closest to an industry standard for mass media, 9-track (V 2 inch) magnetic 
tape serves as a low-cost, high-volume media to store information. And beyond this, mag¬ 
tape is also the most interchangeable media between different hardware and operating 
systems. 

Hewlett-Packard also manufactures a series of V 4 -inch data cartridge tapes which are 
used for the installation and updates of HP-UX on the Series 500. The cartridge tapes 
can also be used for inexpensive backups. These data cartridges, Model HP 88140, have 
most of the benefits of 9-track magtape but are cheaper and easier to handle. 

With the 5.x release of HP-UX on the Series 500, there are new drivers intended to 
optimize I/O throughput to the HP 7974 and HP 7978 magtape drives. This discussion 
will help you effectively and efficiently use the HP 797x series of magnetic tape drive. 

Magtape Definitions 

Here are some common terms and concepts used in the discussion of magnetic tape. 
Consider them required reading if you use magnetic tape. 

coding 

Tape is recorded in several ways. Older systems use Non Return to Zero Immediate 
(NRZI) coding, and record with a tape density of either 200, 556 or 800 bpi. Newer tapes 
use Phase Encoding (PE) and record at 1600 bpi, or they use Group Coded Recording 
(OCR) and record at 6250 bpi. There may be other forms of coding as well, but these are 
the most common. The HP 7970 supports a density of 1600 bpi, the HP 7974 supports 
both 1600 bpi and (optionally) 800 bpi, and HP 7978 magtape drive supports a density 
of 1600 and 6250 bpi. 

The higher the density, the more information can be stored on a tape. On a 2400 foot 
tape, an HP 7974 at 800 bpi can only store 22 Mbytes of data, at 1600 bpi the HP 7974 
can store 43 Mbytes, while an HP 7978 storing at 6250 bpi can write up to 140 Mbytes 
of data to a tape at a rate of up to 16 Mbytes per minute. 
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bpi 

The most common measure of tape density, bpi is an abbreviation for bits per inch, 

cyclic redundancy check 

When writing a tape, a number of frames are written by the drive in a single transaction. 
This collection of frames is called a record. Part of the record, but invisible to the user, 
is a cyclic redundancy check (CRC) recorded as some additional frames on the tape. 
There is a very short blank section between the true record and the CRC. Following the 
CRC is a nominal V 2 -inch gap of unrecorded tape, known as the inter-record gap or IRC. 
The next record follows the gap. When the tape drive reads the tape if either the frame 
parity or the CRC is incorrect, an error is generated by the drive. Newer formats (1600 
bpi and above) generate a preamble and postamble to help synchronize the read logic. 

end of tape 

There is both a logical end of tape (EOT) and a physical EOT (see Figure 3-7). Logical 
EOT is two consecutive file marks. Physical EOT is a foil mark about 25 feet from the 
end of the reel. 2.x and 5.x drivers handle physical EOT differently. See the discussion 
on 2.x and 5.x drivers. 

Note that the distance between the EOT detector and the read/write head may vary 
between different model tape drives. So, one drive may return an EOT indication as¬ 
sociated with the 1000th record on the tape, while another drive may return an EOT 
indication with the 999th or the 1001st record. For small records this variation is large; 
for large records this variation is small. 


Identify 

Burst 


Double File 



Point 


EOT 


Figure 3-7. Magtape Format 
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file marks 

A file mark is a special type of record that can be written to the tape. A file mark is 
recognized by the drive and reported as a boolean condition during reading. Tt is not 
possible to write a file mark as ordinary data; it requires a special command to the drive. 


Single file marks are used to separate logical files on tape. Two consecutive file marks 
are used to signify the logical EOT. Data is undefined past the logical EOT. 

foil mark 

A foil mark is a short piece of silver tape that is placed on one edge of the tape on the 
non-recorded side. Both the load point and the physical end of tape are marked by a foil 
mark. Both marks are placed by the manufacturer. 

load point 

The load point, or beginning of tape, is a foil mark placed about 10 feet from the 
beginning of a tape. When you load a tape (put the tape in the drive, and press “load”), 
the drive searches forward until the load point is found and placed under the sensor. 
The first write is then treated specially: several inches of tape are skipped and then, 
when using PE or GCR formats, a special burst of data is written to the tape (which 
is invisible to the user). This is the identify burst. Data is recorded after the identify 
burst in the usual way. The first read expects the identify burst, and quietly skips over 
it. Some smart drives, such as the HP 7974 and the HP 7978, can determine the tape 
density from the identify burst (1600 and up). 

magnetic tape (magtape) 

Magnetic tape is a media similar to an everyday home cassette tape, used to store digital 
information. All standard magtape is V 2 -inch wide, and comes in three sizes: 600, 1200 
and 2400 foot reels (for a rule of thumb, a 2400 foot reel is about 1 foot in diameter). The 
size of the the reels, hubs, tape width and other mechanical properties are all specified 
by ANSI standard. 

operations 

Several operations that a tape drive can be expected to perform are to read and write to 
the media, rewind to the load point, forward or back space one record, and forward or 
back space to the next file mark. A variation on the theme of rewind is to unload where 
the tape is rewound and taken off line. Some tape drives actually rewind the tape out 
of the threading path; others simply set an interlock that requires manual intervention 
to release. 
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records 

A series of frames written to the media is known as a record. The physical record size 
is variable. The maximum limits on record size range from 16 Kbytes to 60 Kbytes, 
depending upon the tape drive. Beyond these limit, the drive rejects the request and 
there are no write/read retries. The maximum record sizes are: 

Table 3-3. Record Sizes 


Tape 

Drive 

Density 

Record 

Size 

HP 7970 

1600 bpi 

32 Kbytes 

HP 7974 

1600 bpi 

800 bpi 

16 Kbytes 

16 Kbytes 

HP 7978A 

1600 bpi 
6250 bpi 

16 Kbytes 

16 Kbytes 

HP 7978B 

1600 bpi 
6250 bpi 

32 Kbytes 

60 Kbytes 


tape density 

The measure of the amount of information which can be stored in a given area of tape 
is known as tape density. Bits per inch (bpi), a common measure of tape density, is the 
number of bits per track, recorded per inch on the tape. For 9-track tape 8 data bits 
and one parity bit are written across the width of the tape simultaneously. Thus for 
9-track tape, bpi is synonymous with characters per inch (cpi). One of these characters 
is sometimes called a frame. 

tracks 

When digital information is written to a tape, it is written in a series of tracks (a lot 
like an 8-track car stereo). Most magtape today is written in a 9-track format. Older 
systems often wrote only 6 tracks plus a parity bit, resulting in 7 tracks. 

write/read re-tries 

Tape, in its usage for long-term archive and data interchange, is somewhat more prone 
to error than disks. When your tape drive is reading from, or writing to, a tape and it 
detects an error, the normal procedure is to position the write head at the beginning of 
the record and retry the tape operation. An error message is reported to the user only 
after some number of retries (the number depends on the driver). Many more tape errors 
are caused by dirty tape heads than by real recording errors, so you should periodically 
clean your tape drive as outlined in its service manual. 
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Tape drives do a form of reading-while-writing, and if the data is not properly recorded 
an error will be detected. The normal procedure is to backspace and re-tr>^ wanting the 
record once, and if that fails, to backspace, write a long gap and try again on a section 
of tape farther down. A long gap is several inches of erased tape. That’s why we said an 
IRG is “nominally” V 2 inch long. 

write ring 

On the back of the reel there is a removable soft plastic write ring. Every magtape 
drive has a sensor mechanism to detect the presence of this ring. When a ring is present 
the tape can be written to by the host, and cannot be written when absent (it is write 
protected). Normally once a tape is written the ring is removed and left out indefinitely 
except when being rewritten. 

Preventive Maintenance 

There are several maintenance procedures for tape. A tape can be completely erased 
(degaussed), or the beginning of the tape can be discarded and a new load point put on 
(stripped). There is also a tape cleaning and certifying machine that will knock off any 
loose oxide and check that the tape will record properly over its full length (certified). 
This always makes any data on the tape unusable. Commercial shops certify their tapes 
fairly often, and discard them if they get too short or fail to certify. It is also an 
excellent idea to clean the tape head and guides of your drive periodically as they tend 
to accumulate loose oxide. 

Tape Streaming 

The HP 7970 transfers data to and from your Series 500 with very little buffering between 
your computer and your drive’s read/write head; the drive must stop the tape between 
records, and wait for the next record. HP 7970 is called a start/stop tape drive, and is 
designed to stop and restart the tape fairly quickly. 

The HP 7974 and HP 7978 are streaming magnetic tape drives. A streaming magnetic 
tape drive is designed to move continuously, reading data from a buffer or writing data to 
a buffer, not stopping between records like start/stop tape drives do. Streaming increases 
the rate at which a tape drive can write data onto tape. Before a tape drive can write 
data onto a tape, the drive read/write head must be positioned at the proper place on 
the tape, and the tape must move across the head at the proper speed. After writing a 
record on the tape, if a streaming drive has already received the data for the next record 
from the computer, it can continue to move the tape across the head without slowing 
down to write the next record. 
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If the drive has not received the data for the next record after writing a record on the 
tape, then the drive must reposition the tape. This involves stopping the forward motion 
of the tape, backspacing the tape to some point proceeding the beginning of the next 
record to be written, stopping the tape, and waiting for your computer to send the 
data for the next record. The average data transfer rate is much higher when the drive 
streams than when it repositions, especially for the HP 7978. The HP 7974 supports 
both a start-stop and a streaming mode. The HP 7978 supports only a streaming mode. 
Both drives are much faster than the HP 7970 when they stream. When they do not 
receive data fast enough to stream, the HP 7974’s performance is similar to the HP 7970; 
the HP 7978 is much slower. 

Immediate Response 

To help your computer send data fast enough to permit the drive to stream, the HP 7974 
and HP 7978 support immediate response mode. Ordinarily the actions of your computer 
and the drive are serialized. Your computer sends data to the drive. Then the drive writes 
the data to the tape. After the data is written, the drive returns status information to 
the host indicating whether the write succeeded or failed. When immediate response is 
enabled the drive returns status before it writes the data to the tape. 

This is accomplished by the drive buffering the data it receives from your computer in 
high-speed memory which is built into the drive. The transfer rate between the host and 
this buffer memory is much faster than the transfer rate would be if the drive transferred 
the data directly to the tape. Because the drive returns status to your computer very 
quickly the host’s and the drive’s activities overlap, so the average transfer rate to the 
drive has a much better chance of being fast enough to permit the drive to stream. Even 
when the drive has to go through a reposition cycle, it can still be buffering additional 
records from the host. 

Even with immediate response enabled the HP 7974 and HP 7978 tape drives typically 
don’t stream continuously because the programs running on your Series 500 don’t collect 
their data from the disk fast enough to supply it to the tape drive. However, they still 
perform faster than the HP 7970 stop/start tape drive. 

An identical concept applied to CS/80 cartridge tape is referred to as immediate report. 
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Version 4.2 Drivers 

The version 4.2 and 5.x drivers treat records written across or beyond the physical end 
of tape mark differently. The Series 500 4.2 HP 7970 device driver reports an error on 
read or write if a record crosses physical EOT. When writing on multiple reels, the 4.2 
driver will finish writing the record, but since writing that record generated an error the 
application (e.g. cpio) will re-write the record on the next tape. The record that crosses 
physical EOT is called a “phantom” record; though the record is written at the end of 
one tape, it is written again at the beginning of the next tape. Reading the phantom 
record also generates an error; applications using the 4.2 drivers will receive a read error, 
and will not use the phantom record. 

Version 5.x Drivers 

For the 5.x revision of the Series 500 HP-UX kernel, the HP 7974 and HP 7978 drivers 
support immediate response mode by default. For single-reel magtape archives, the 
only consequence of this change is that the drive streams more when it writes, and 
so it writes faster; you can still interchange tapes between 4.2 and 5.x drivers. For 
multiple-reel magtape archives, the consequence of this change is that you can no longer 
interchange tapes between 4.2 and 5.x drivers without setting a compatibility mode bit 
(see “Backward Compatibility” below). Without compatibility mode, the “phantom” 
record of the 4.2 multiple-reel archive will be read from both tapes on drives using 
immediate response. In particular, cpio from one version will not correctly read multiple 
tapes created from the other version. 

Backward Compatibility 

The 5.x version HP 7974 and HP 7978 drivers support a non-default 4.2 compatibility 
mode which the user may select by setting the third least significant bit in the device file 
minor unit number (i.e., 0x000008). In this mode these drivers can read and write tapes 
with 4.2 end-of-tape semantics. The only time you need to set the compatibility mode 
bit is when you are reading 4.2-written tapes with a 5.x driver, or when you are writing 
a tape with a 5.x driver to be read by a 4.2 driver. When the compatibility mode bit is 
set, the HP 7974 and HP 7978 will have a slower writing rate. 

If you are sure you have a tape written by a Series 500, 4.2 driver, then you have the 
“phantom” record. The only way you could have a phantom record is if you wrote the 
tape using an HP 7970 driver, version 4.2. If you delete this phantom record, you will no 
longer need to run your 5.x driver in compatibility mode. 
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Note 

Before you try to delete the phantom record, make sure you have 
the phantom record. 


To delete the phantom record (assuming you have only one file that crosses over more 
than one tape), load the tape and type in the following: 


Type in: 

Description 

mt rew 

rewind the tape 

mt fsf 

skip past the first file marker 

mt bsr 2 

backspace over the first file marker and 


the phantom record 

mt eof 2 

write a new logical EOT (new double file 


mark) 

mt rew 

rewind the tape 
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Memory Management 

Your computer is equipped with a large but finite amount of Random Access Memory 
(RAM). It is important that you understand the manner in which this valuable system 
resource is used since you, in part, control its allocation through system configuration. 

Memory Allocation 

Before you consider the manner in which memory is allocated, you must understand some 
fundamental memory concepts. The basic concepts of memory allocation are determined 
by the computer’s hardware architecture, not by the operating system. Thus, some terms 
and concepts that explain the computer’s memory management are presented first. Then 
HP-UX’s methods of memory allocation and management are presented. 

Your Series 500 computer is a 32-bit computer. With 32 bits, an absolute pointer can 
address 4 294 967 296 different bytes of memory. Three of the 32 bits are used by the 
system for purposes other than addressing. This leaves the system with 29 bits with 
which to address absolute physical memory. Thus, the system can address 536 870 912 
bytes or 2^^ bytes (the range of addresses is called the absolute address space). 

This limit of 2^^ bytes on the absolute physical address space is inconsequential since 
it is not possible to physically fit 500 MBytes of real memory in the machine! Each 
user, however, can address 31 bits of logical address space through pointers translated 
by segment tables. Each user in a multi-user system has her own private 30-bit virtual 
address space plus simultaneous access to the system’s 30-bit virtual address space shared 
by all users on the system. 

Mapping RAM to Absolute Address Space 

Although the computer can address the entire absolute address space, it is equipped 
with a much smaller amount of Random Access Memory (RAM) hardware. This amount 
depends on the number and type of RAM boards that are installed. There are four types 
of RAM boards available for the Series 500: 

• 256 Kbyte RAM (HP 97040A) 

• 512 Kbyte RAM (HP 97047A) 

• 1 Mbyte RAM (HP 97046A) 

• 2 Mbyte RAM (HP97048A) (see section “2 Mbyte RAM Notes”) 
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The 2 Mbyte RAM board contains two memory controllers, the other three each contain 
one memory controller. A memory controller provides the means to map (assign) the 
physical memory into the absolute address space. The memory is mapped contiguously 
from absolute memory address zero. In nearly all instances, the 1 Mbyte RAM is mapped 
first, starting at absolute memory address zero, and then the 256 Kbyte RAM and 512 
Kbyte RAM are mapped. The 2 Mbyte RAM functions as though it were two 1 Mbyte 
RAM boards on one board. 

The 1 Mbyte RAM is somewhat slower than the 256 Kbyte RAM and the 512 Kbyte 
RAM; therefore, it is interleaved to improve its performance. The interleave can be 
one-way, two-way, four-way, or eight-way; the higher the interleave, the better the per¬ 
formance. 

The interleave of the memory supplied by 1 Mbyte RAM boards is determined by group¬ 
ing the memory into one, two, four, and eight Mbytes, where each group has the associ¬ 
ated interleave. For example: 

• If you have four 1 Mbyte RAM boards, the four Mbytes of memory have a four-way 
interleave. 

• If you have three 1 Mbyte RAM boards, two Mbytes of memory have a two- way 
interleave, while the third has a one-way interleave. 

• If you only have one 1 Mbyte board, the one Mbyte of memory has a one-way 
interleave. 

In some configurations, adding an extra 1 Mbyte RAM to a system can result in a 
performance degradation. It is important that the memory have the highest interleave 
possible in order to maximize performance. A Series 500 with four 1 Mbyte RAM boards 
has four-way interleaved memory throughout the absolute address space. If another 1 
Mbyte RAM is added, four Mbytes of memory have a four-way interleave and one Mbyte 
has a one-way interleave. That one Mbyte of memory having a one-way interleave may 
cause a net loss in system performance. 

Note that since the memory supplied by 256 Kbyte RAM and 512 Kbyte RAM boards 
is not interleaved, it has a set performance level that is not changed by how the boards 
are combined in a system. 
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2 Mbyte RAM Notes 

The 2 Mbyte RAM board can be thought of as two 1 Mbyte RAM boards in one package. 
There are two cases where the 2 Mbyte RAM does not work as expected: 

1. If you have 1 CPU board, 1 lOP, AND either 12 or 13 Mbytes of memory 
(HP 97046A or HP 97048A), then the system won’t boot. 

2. This second situation is for the Model 550 only. 

If you have a kernel earlier than 5.11 AND you have your 2 Mbyte RAM installed 
below a display station buffer in the stack, then the system will terminate abnor¬ 
mally (with a dump to the console). 


Dividing the Absolute Address Space 

The absolute address space is divided into two regions: the fixed region and the dynamic 
region. 
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The fixed region contains space for the hardware-defined locations, the system segment 
table, system data structures, and system code. The size of this region is determined at 
power-up and it is accessible only to the operating system. 

The dynamic region is split into three areas: the paging area, the segment area, and the 
buffer area. 
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The paging area is used for paged segments (see “Paged External Data Segments” later in 
this chapter) and is managed by the virtual memory system. The segment area contains 
all other segments and is the principle source for free space. The buffer area contains 
buffers used by the system for objects that cannot move. The boundaries between these 
three areas are dynamic and change as the system load shifts between activities associated 
with each area. 
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Partitions 

The system provides 512 partitions, one of which is reserved for the system. A partition 
is a logical section of memory composed of: 

• a process 

• an address space consisting of a collection of memory segments managed by a 

segment table. 

Each partition has one segment table that points to segments in the segment area that 
are used by the associated process. A user process accesses memory segments through its 
segment table. The segment table is managed by HP-UX; it is not directly accessible to 
the user process. Although one user process cannot directly access another user process’ 
memory, it is possible for one process to force the suspension of another process, in which 
case the system reassigns the partition’s memory. 

The partition reserved by the system is called the system partition. It is used for code 
and data segments which may be shared between different user processes. This is possible 
since the system segment table is accessible to all other partitions. 

Each user process uses: 

• one or more code segments (CS) - segments containing the code that the process is 
executing. 

• a stack segment (SS) - a segment that contains procedural parameters, the return 
addresses for procedures calls, and local variables for procedures. 

The stack segment is used for variables which are allocated when a procedure is 
called and are de-allocated when the procedure returns. The size of this segment 
grows as needed by the executing program. The stack segment only shrinks during 
an exec, though the logical stack size grows and shrinks dynamically. The stack is 
limited to a maximum size which is determined by the system configuration. 
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• a global data segment (GDS) - a segment that holds the program’s global data (for 
example, statically allocated data). 

The global data statement is used for variables which are allocated when a program 
is loaded. These variables remain in memory for the duration of the program and 
are de-allocated when the program terminates. A GDS can be removed to disk in 
response to memory demand. 

• one or more external data segments (EDS) 


External data segments are general purpose segments. They are used mainly for 
data. Because of attributes discussed later in this chapter, they can allow access to 
extremely large quantities of data. 

Stack and global data are “fast access” segments. The system has mechanisms which 
allow the data they contain to be read and written faster than external data segments. 
Any virtual segment is subject to removal in response to memory demands of higher 
priority processes. 

Virtual Memory 

When a program executes, it typically performs one function (such as totalling an em¬ 
ployee’s hours) and passes its output on to another function within the same program 
(such as a wage calculating program or a paycheck program). Although the entire pro¬ 
gram is loaded into memory, only one such function is used at any one time. The 
remaining portions of the program may sit idly by, possibly occupying memory. 

As you learned with the memory allocation concept, memory is mapped to a partition 
to hold the process’ code and data segments. Without virtual memory, if there is not 
enough memory available for a process’ segments, the process cannot execute; it must 
wait until sufficient memory is free to be mapped to its partition. When large programs 
or programs that access large amounts of non-virtual data are run, they must wait until 
few processes are running so that they may acquire the memory needed for their partition. 
Then, once running, other processes must wait for the large process to terminate before 
they can run (even though the large program may only be using a few segments and a 
small amount of memory at any given time). This also implies that no process can exceed 
the total memory size of the computer (since there is no way for sufficient memory to be 
mapped to the process’ partition). 
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To avoid this restriction, HP-UX has implemented a memory management attribute, 
called virtual memory. Segments composing an executable file are marked virtual or 
non-virtual with the /usr/bin/chatr command. The segments of the file are marked as 
virtual segments by default when the compiled objects are linked with the Id command. 
When you execute virtual code or access virtual data, the system places those segments 
that are currently needed into the available memory within the process’ partition. If 
there are more segments in the object than memory available, the additional virtual 
segments are copied to files on the virtual memory device. You specify which device is 
the virtual memory device when you configure the system. 

When the executing code attempts to access a segment that is not present in memory, 
the system attempts to map additional memory to the process’ partition. If the addi¬ 
tional memory is not available, the system attempts to free memory that contains virtual 
segments no longer needed. These segments are “swapped out” (copied out) to files on 
the virtual memory device and the needed segments are “swapped in” to the newly freed 
memory. Because of the way that virtual memory is implemented, the “virtual address 
space” is much larger than the absolute address space of the process’ partition. 
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Figure 3-8. Virtual Address Space 
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In determining which segments to swap out, HP-UX uses the following criteria. No 
segments are swapped out until additional memory is needed. When memory is needed 
(to swap in a virtual segment being accessed), the system looks for any virtual segment 
that has been resident longer than a set length of time without being accessed. Segments 
meeting that criteria are “swapped out” until enough memory is free to load the needed 
segment. The set length of time referred to previously is specified with the system 
configuration. If no segment has been in memory without being accessed for the set 
length of time, the system attempts to recover memory through a variety of tactics, 
including suspending lower priority processes and using their memory and attempting 
to shrink the page frame pool. If the request still cannot be granted, the requesting 
process can be suspended until the system determines that enough memory is available 
to resume that process. 

Since only the segment currently needed is loaded at any one time, your programs and 
data may actually be larger than the physical memory within the computer. The max¬ 
imum size of a virtual program is about 500 Mbytes. Similarly, the maximum size of 
virtual programs that utilize the system partition (such as shared code segments) is about 
500 Mbytes. 

Virtual Memory: Benefits vs. Cost 

Making segments virtual dramatically reduces the amount of memory required by each 
user partition. However, the costs of virtual memory are extensive. Virtual code segments 
often occupy twice their original space on disk: one non-virtual copy (the original copy) 
and one copy of the file in the virtual address space. Additionally, each time the computer 
swaps a segment in or out, time is required to copy the program to/from disk. Thus, the 
program runs more slowly. As more users utilize memory, the computer must do more 
and more swapping. 
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Shared Code 

Often, several processes want to run the same program simultaneously (such as a text 
editor program). If the program is not shared, then each process running the program 
has a copy of the program’s code and data. If the processes share one copy of the code, 
the amount of memory required for each process’ partition dramatically decreases. 

The term shared code describes user code which is loaded into the system partition. 
When a process executes shared code, it is directed to the copy of the code in the 
system partition. If the shared code is not yet loaded (no other process is currently 
accessing the code), the code is first loaded into the system partition before the process 
begins execution. Only one copy of the code exists in memory regardless of the number of 
processing running the program. When all processes accessing the shared code terminate, 
the memory in the system partition in which the shared code currently resides becomes 
available to satisfy requests for memory (unless the sticky bit was set on the file from 
which the code was loaded). The memory is not actually freed until a process requires 
it. 

The system knows how many users are accessing shared code by maintaining a count 
(called the use count) of the number of processes accessing the code. When a shared 
program is loaded into the system partition, the use count for the program is set to one. 
When the process finishes executing the code, the use count is decremented. 

For example, suppose that the text processor program ed is marked “shared”. When a 
process first executes ed, its code segments are loaded into the system partition and its 
use count is set to one. Suppose that while the first process is executing ed, another 
process executes the ed program. Since the code already resides in the system partition, 
no additional memory is allocated. The new process simply executes the copy of ed’s code 
that resides in the system partition; its use count is incremented from one to two. The 
first process now finishes editing and terminates the ed program. The system decrements 
the use count of ed’s shared code. Since the use count is not yet zero, the shared code 
remains in memory. Finally, the second process finishes editing and terminates the ed 
program. The system decrements the use count of ed’s shared code segment and, finding 
its value to be zero, makes ed’s shared code segments available for use by other programs. 

See ld(l) and chatr(l) for information about making programs shareable or non- 
shareable. 
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Shared Code and the Sticky Bit 

Setting the sticky bit on a file containing shared code increments the shared code’s use 
count by two instead of one when the shared code is loaded into the system partition. 
This keeps the use count from ever returning to zero, thus keeping the shared code 
segment in memory whether it is being accessed or not. 

For exam.ple, suppose that the text processor program ed is marked “shared”. Also 
suppose that the sticky bit for the file in which ed is stored is set. When a process first 
executes ed, the shared code is loaded into the system partition and its use count is set to 
two. Suppose that while the first process is executing, another process executes ed. The 
new process executes the copy of ed’s code that resides in the system partition; the use 
count of the shared code is incremented from two to three. The first process now finishes 
editing and terminates its execution of the ed program. The use count of the shared 
code decrements from three to two as the second process continues to edit. When the 
second process finishes editing, it terminates execution of the ed program. The use count 
of the shared segment decrements from two to one. Note that even though no process 
is accessing the shared code, its use count does not decrement to zero. The shared code 
remains in memory; the memory is not freed for other uses. 

To return the use count of a “shared”, “sticky” program to zero, the super-user must 
set the mode bits of the file containing the program such that the sticky bit is no longer 
set. When the program is again executed, the system recognizes that the sticky bit is no 
longer set and decrements the use count. 

Shared Code: Benefits vs. Cost 

Shared code significantly reduces the amount of memory required for process partitions 
when multiple processes are executing the same program. There is no cost associated 
with sharing code unless the file containing the shared code has its sticky bit set, or the 
system segment table overflows due to an excessive number of shared objects. In this 
case, the code occupies memory in the system partition whether the code is being used 
or not. Consider making such code virtual as well as shared and “sticky”. Since the 
number of shared code segments in the system is limited by the number of entries in 
the shared system segment table, overuse of sharing can result in system segment table 
overflow errors. 
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Demand Load 

Programs often contain routines and code which are rarely accessed. For example, error 
handling routines can comprise 80% or more of some program code and yet may be rarely 
accessed. As mentioned previously, when a program is loaded, it is copied in its entirety 
into main memory. If the unused code segments are a significant portion of the program, 
the memory allocated for that code is wasted. 

With HP-UX, it is possible to mark code segments, data segments, and data pages 
(discussed later) as demand loadable. When a demand loadable segment is requested 
to be loaded, no segments are actually loaded. Instead, a bit is set specifying that the 
segment is demand-loadable; the system is ‘Pooled” into believing that the segment is 
actually present in memory even though it is not. No memory is allocated for the non- 
loaded segments until those segments are actually accessed. Only when the program 
attempts to access a demand-loadable segment is memory actually allocated and the 
segment loaded from disk. 

To make code demand-loadable, mark the segments that you want demand-loadable when 
the compiled code is linked (via the -z option of the Id command). Alternately, you can 
use the /usr/bin/chatr command to mark an existing executable file as demand-loadable. 
You can change a demand-loadable file such that it is no longer demand-loadable by using 
the chatr command. 

Demand Load: Benefits vs. Cost 

Making code segments demand-loadable reduces the amount of memory allocated for 
a user’s partition. However, the program may actually take longer to execute than 
a program that is not demand-loadable if many of the demand-loadable segments are 
accessed. 

Note that memory blocks are not allocated until the segment is actually accessed. Thus, 
if there is insufficient memory for the segment, an error will occur while the program 
is running; the program fails. If the demand-loadable attribute is not used, the lack of 
memory is detected when the program is loaded (because memory is allocated when a 
program is loaded). 
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Paged External Data Segments 

A limitation of virtual memory as discussed so far is that all of an external data seg¬ 
ment used by a program must be resident in memory when that segment is accessed. 
Suppose that you have written a program to analyze 30 Mbytes of data. (For exam¬ 
ple, finite element analysis programs and circuit analysis programs both use extremely 
large quantities of data.) That means that when your program runs, all 30 Mbytes of 
data need to be present in a process’ partition, if the data was allocated in one unpaged 
EDS. However, your system does not have enough memory to hold the data. Even if 
the system had 30 Mbytes of memory to map into the partition, your program would be 
using so much memory that other users would not be able to do anything. Typically, 
you only need to access a small portion of that data at any one time. The remainder 
of the data simply sits in memory, occupying system resources. To solve this problem, 
HP-UX allows virtual external data segments to be paged. 

A paged segment is a segment that is divided into parts of a fixed size called pages (1024 
bytes is the default). The segment table, instead of storing the size and location of the 
entire segment (as is the case with un-paged virtual segments), stores a pointer to a page 
table. A page table is an ordered table indicating the address of each page in memory 
for the segment. If the page is currently on the disk, then the page table stores its disk 
location. The virtual memory system then moves virtual pages in and out of memory as 
needed, just as the virtual memory system moved entire segments in and out of memory 
in the previous discussion. 

Not all pages of a segment have to be in memory at any given time. Thus, only a portion 
of a segment must be in memory at any given time, not the entire segment. This allows 
the segment to be larger than the size of memory, and still be accessed by the process; 
only the page being currently accessed must be resident in memory. Additionally, since 
each page is uniform in size, the virtual memory system can easily decide where to place 
the pages in memory. If one page is removed, then any other page can fit into its place. 

The memory used for the pages of all the paged segments is allocated from a kind of 
memory “parking lot”, called the page frame pool. When an executing program needs 
access to a paged external data segment, the system allocates the appropriate number 
of pages in the page frame pool and loads only that data into the pages. The memory 
pages are returned to a “free list” in the system’s page frame pool when the process 
terminates. 

When a new page is needed (a non-memory resident page is accessed) and there is not 
enough memory in the page frame pool, a page is swapped out to the virtual memory 
device. When a page is needed and is not resident, it is swapped in from the virtual 
memory device. 
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All paged segments in the system compete for the use of pages in the page frame pool. If 
no paged segments are active, then memory allocated to the page frame pool can be used 
for segments (for example, mapped to a process’ partition) until the memory is needed 
by a paged segment. The maximum size of the page frame pool (and the size of each 
page) is determined by the system configuration. Page sizes are powers of two in the 
range 512 to 8 192. Programs that access pages in sequential patterns usually benefit 
from larger page sizes, while those that access pages randomly benefit from smaller page 
sizes. 

Pages that are currently in the page frame pool and are entered into the page table for 
a particular segment are known as working set pages. The working set pages are linked 
together in a per segment list by the virtual memory system. The system provides a 
method to guarantee that a certain number of pages (called the guaranteed working set) 
are always available for a specific segment. 

All pages that are not in the working sets of allocated paged segments fall into three 
categories: 

• dirty pages pages that were removed from a working set and must be written 
back to the disk before they can be re-assigned to another working set. 

• used pages - pages that were removed from a working set and were not modified 
since being read into memory (and thus do not have to be written back to the disk). 

• free pages — pages that are available for use and have no valid data in them. 
All pages start out as free pages. If a segment is de-allocated, then all the pages 
associated with it are placed in the free list. 

All pages removed from some segment’s working set are placed in either the list of used 
pages or the list of dirty pages, depending on whether they were modified. The dirty and 
used lists are maintained for the instance when a page is removed from a working set, is 
not written back to disk yet, and then is requested again. The dirty or used page can be 
restored to a working set much faster than if it had to be read back from the disk. 

External data segments are automatically specified to be paged when the data objects are 
lined via the id command. Additionally, you may specify that data is to be paged with 
the Extended Memory System (via the ems system call). You can use the /usr/bin/chatr 
command to specify that an existing paged external data segment is not to be paged. 
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Page Clustering 

The system recognizes three types of paged access: 

• sequentiai 

• random 

• normal 

Sequentiai accessing occurs when a paged segment is accessed linearly in either direction. 
Random accessing occurs when there is no pattern or locality associated with the data 
accesses. Normal accessing has a high degree of locality with occasional occurrences 
of sequential and random accessing. The performance of sequential accessing can be 
improved by taking advantage of page clustering. 

You can force page clustering by specifying the referencing pattern of an area of process 
memory as sequential with memadvise. Once page clustering is enabled for a paged object, 
one or more sequential pages will be read into memory whenever a page fault is detected. 
This reduces the number of page faults that occurs during sequential accessing. You also 
specify the size of the page cluster with memadvise. See the entry for memadvise(2) in 
the HP-UX Reference for more information. 

With normal accessing (the system default), the system automatically enables page clus¬ 
tering when it detects a series of sequential page accesses. No clustering is ever attempted 
when a paged segment is marked as random. 

Paging Benefits vs. Costs 

The chief benefit of paging is that it allows a process to use quantities of data that exceed 
the physical memory limits of the computer. The maximum amount of memory allocated 
to the page pool is specified by the system configuration. Memory allocated to the page 
pool cannot be allocated to process partition(s). 

A primary cost of paging data is the time required to read the file each time a page 
is read from disk. An additional cost of paging data is the time required to access the 
page. Each time a page is accessed, the process must first access the partition segment 
table, then access the page table (an external data segment) and then access the page 
(and possibly wait for it to be swapped in, if it is not already memory resident); access 
to paged external data segments is slower than accessing external data segments resident 
in the process’ partition. 
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Combining Memory Management Tools 

The memory management attributes previously discussed can be used in any combina¬ 
tion, with some restrictions. These restrictions are: 

• code segments cannot be paged. 

• setting a file’s sticky bit affects only the code segments in shared programs. 

• global data segments cannot be paged or demand loaded. 

• stack segments are always virtual and cannot be paged or demand loaded. 

Wise system adminstration calls for a mixture of the memory management attributes 
previously discussed. Most program files should be shared, virtual, paged, demand load¬ 
able or some combination of these. Your system is shipped with a proper mixture for 
the ‘‘average system”. The system configuration, as shipped, is set up for the same “av¬ 
erage system”. The average system is based on a Series 500 computer equipped with 1.5 
Mbytes of memory with an environment of the following four concurrently active tasks: 

• compilation of a FORTRAN program. 

• random and sequential read and write access to elements in a 2 Mbyte virtual array. 

• execution of a computationally intensive program, 

• invocation of interactive commands (such as editing or listing the contents of a file). 

By changing the mixture, altering the system configuration and observing the change in 
system response, you can “tune” the system for the optimum response for your applica¬ 
tion mix. 
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The Buffer Cache 

Program code and the data which it uses must be transferred from disk into physical 
memory before it can be executed. The manner in which code is transferred depends 
on the attributes of the code and the manner in which the code is executed. All code 
executed via the exec system call is transferred into the process’ partition via a buffer 
called the file system buffer cache. Additionally, most data that is read from or written 
to disk is transferred through the file system buffer cache. 


The file system buffer cache is a collection of one or more buffers w^hich the system uses as 
a temporary holding place for code/data being transferred between the disk and physical 
memory. The size of each buffer and the number of buffers in the cache is specified when 
the system is configured. As the code and data are moved into the buffer cache, the 
system copies the information from the buffer cache into the user’s partition. 

The buffer cache can be thought of as a long tube (with sections of uniform size) that 
is shared by all processes. When code and data are loaded into the system, the system 
reads a portion of the file, equal in size to one buffer and places it in the tube. The 
system repeats this procedure until the entire program is transferred. When another 
program is loaded, it is placed into the tube behind the previously loaded program. This 
continues until there is not enough space in the file system buffer cache to load the next 
program. At that time, the last recently accessed program is removed from the cache 
until there is enough room to load the new program. 

If a user requests a program that is already in the buffer cache, the program is copied 
from the cache to the user’s partition, eliminating the intermediate step of copying the 
file from disk to the buffer. The copy of the program in the buffer cache is then moved 
to the beginning of the cache, indicating that it is the most recently accessed program 
(and thus placing it last in the queue to be removed from the cache). 

The primary advantage of the file system buffer cache is the speed with which large 
numbers of sequential reads are made to a data file. This advantage is largely due to an 
attribute of the file system buffer cache, called the read ahead level. 
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Read Ahead Level 

The file system buffer cache has an attribute called the read ahead level. It is applicable 
primarily to users who are reading data from the disk with system calls. The read ahead 
level is the number of “buffers-full” of contiguous data the system should attempt to copy 
per disk access. For example, assume the read ahead level is four and a user is attempting 
to read 256 bytes of data from a file (via a system call). When the file is accessed, you 
would expect only the requested number of bytes to be copied into the buffer cache and 
then into the user’s partition. However, because the read ahead level is four, the system 
attempts to copy enough data to fill four cache buffers. Only the requested 256 bytes are 
copied from the cache into the user’s partition. The remaining data stays in the cache 
in anticipation of the user’s next data read request. Since the system has to access the 
disk (a time consuming process) to copy the requested 256 bytes, it might as well copy 
some additional data (up to a maximum specified by the read ahead level) the user is 
likely to need. 

Data accessed in this manner must be contiguous and accessed sequentially. For example, 
assume a user is attempting to access 256 bytes of data from a file consisting of two extents 
(the first extent contains 2 Kbytes, the second contains 3 Kbytes). Also assume that each 
cache buffer is 1 Kbyte in size and that the read ahead level is four. When the user reads 
the first extent to access the requested 256 bytes, the system examines the read ahead 
level and attempts to copy 4 Kbytes (4 x IK/buffer). However, after copying the first 
2 Kbytes of data into the cache, it encounters the end of the extent and terminates the 
copy. Thus, only 2 Kbytes of data were copied into the buffer cache. 

The File System Buffer Cache: Benefits vs. Cost 

The primary benefit of the buffer cache is the increased speed with which large numbers 
of sequential or repeated data accesses are made. When the first of such transfers is 
made, the system recognizes that a sequential access has begun and attempts to read 
enough additional data to fill the read ahead level. Then when additional sequential 
accesses are made, the data is already present in memory, in the file system buffer cache. 
Thus less time is required to access the data after sequential access is detected. 

Transferring a program from the buffer cache to a process’ partition is much faster 
than transferring a program from disk, through the buffer cache, to a process* partition. 
Thus by increasing the size of the buffer cache, more program and file data can be 
held in memory and the apparent system response time decreases. However, memory 
used by the system cache is unavailable for use in user partitions and thus decreases 
that precious system resource. When the file system buffer cache exceeds a certain size, 
system performance begins to decrease since less memory is available for other system 
functions. 
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A major factor in determining the ideal size of the file system buffer cache is the amount 
of memory in the system. For a system with 2.0 — 2.5 Mbytes of RAM, performance 
begins to degrade when the cache is larger than 50 - 100 Kbytes. However, for a system 
with 4.0 - 8.0 Mbytes performance may not begin to degrade until the cache exceeds 
200 - 800 Kbytes. The ideal size for the buffer cache also depends on such things as the 
amount of sequential data access performed and the speed of the disk drive. By default, 
the system, chooses a reasonable size buffer cache based on the available memory in the 
system. The system administrator can alter the default size if she desires. 

As a rule of thumb, consider that as the size of the buffer cache increases, the probability 
of accessing a segment via the cache increases and the probability of accessing a segment 
via the disk decreases. However, as the size of the cache increases, the amount of physical 
memory available decreases (thus decreasing the performance of other processes). 


Peripheral Device I/O 

HP-UX treats Input/Output (I/O) to a peripheral device in the same fashion as I/O to 
a file. In fact, before your computer can “talk” to a device, a file (called a device file) 
must be created. This file defines the location of the device and the manner in which 
the computer and the device must communicate. Device files are created with the mknod 
or mkdev commands and are usually stored in the /dev directory. To communicate with 
a device, simply redirect input from, or output to, the device file. The computer then 
uses the information contained in the special file to manage all transfer of data between 
it and the device. 

Device Classes 

All I/O devices can be classified as either block or character devices. Block devices 
are devices which transmit and receive data in blocks (typically I block 1024 bytes, 
but the size of a block, is specified when initialized). Typically, block devices are disk 
mass storage devices. However, a disk’s built-in cartridge tape drive (available with 
HP 7908, HP 7911, HP 7912 or HP 7914 disk drives) and other magnetic tape drives are 
occasionally used as block devices. Character devices include any device which is not 
a block device, including printers, plotters, terminals, magnetic tape drives, and paper 
tape punches/readers. Disk mass storage devices are occasionally treated as character 
devices, even though they normally operate as block devices. 
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Drivers 

The mknod command creates a device file from a driver number (also called major num> 
her), an address (also called minor number, and is defined next) and a driver. A driver is 
compiled code (supplied with your system) which defines the protocol and handshaking 
that allow an I/O device and the computer to communicate. For more information on 
drivers refer to the section “Modifying the Boot Area” in the “Toolbox” chapter. For 
more information on the mknod command refer to the section “Adding/Moving Peripheral 
Devices” in the “Toolbox” chapter. 

Address 

An address is a set of values which specify the location of an I/O device to the computer. 
The address is composed of up to four hexadecimal fields; the select code field, the bus 
address field, the unit field, and the volume field. An address is specified in a packed 
field that has the form: 

OxScAdUV 

Ox A two-character field specifying that the following field is a packed hexadecimal 
field. This must be typed in as the characters 0 (the number 0, not the letter O) 
and X. 

Sc A two-digit hexadecimal value specifying the select code. 

The select code is determined by the I/O slot in which the device’s interface card 
is installed. Refer to your computer’s installation manual, the section describing 
the installation of interface cards, for more information. 

Ad A two-digit hexadecimal value specifying the port number or HP-IB bus address. 

The bus address allows the computer to distinguish between two devices connected 
via the same HP-IB interface. Refer to the manual supplied with the peripheral 
to determine if the device has an address, and the method in which that address 
may be changed. 

U A single-digit hexadecimal value specifying the unit number. The unit number’s 
meaning depends on the type of peripheral device. 

V A single-digit hexadecimal value specifying the volume number. The volume num¬ 
ber’s meaning depends on the type of peripheral device. 

For a precise definition of these fields, refer to the discussion entitled “Adding/Moving 
Peripheral Devices” in this manual. 
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The HP-UX Hierarchy 

The file system of HP-UX is organized in a tree structure. The base of the tree is the 
root of the file system, and the file name / is associated with the root. Under the root 
are nine standard directories created when you installed your system: bin, dev, etc, 
lib. public, system, tmp, users, and usr. 

This section describes the basic purpose of the major directories in your HP-UX tree. 
You will find this useful as you add files and modify your system in the future. As you 
read the descriptions, reference them to Figure 3-9. 

• /bin—contains frequently used commands, and those required to boot, restore, 
recover and/or repair the system. 

• /dev— contains special device files used to communicate to peripherals. For more 
information, see mknod(lM). 

• /etc —all system administrative commands and configuration files reside here. 

• /etc/newconf ig —new versions of customizable configuration files and shell scripts 
are stored here following an update. You should keep these files intact here for 
future reference. 

• /lib frequently used object code libraries and related utilities are placed in this 
directory. 

• /public—used for free access of files to other systems via uucp or LAN. 

• /system —contains object code for drivers; also contains the boot area. 

• /tmp —a place to put temporary files (those normally with short lifetimes and which 
may be removed without notice). 

• /users —user home directories go below this directory. 

• /usr —less frequently used commands and other miscellaneous files are stuck under 
this directory. 

• /usr/adm —system administrative data files lay here. 

• /usr/bin— less frequently used commands and those not required to boot, restore, 
recover, and/or repair the system go here. 

• /usr/include— high-level C language header files (shared definitions). 
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• /usr/include/sys low-level (kernel-related) C language header files. 

• /usr/include/local localized C language header files. 

• /usr/lib—less frequently used object code libraries, related utilities, and miscella¬ 
neous data files go here. 

• /usr/local—localized files should be placed here. 

• /usr/local/bin—localized commands should go here. 

• /usr/local/lib localized object code libraries are placed here. 

• /usr/local/man put any on-line manual pages for localized systems in this direc¬ 
tory. 

• /usr/mail—where your mail box resides. 

• /usr/man—all on-line documentation shipped with your system can be found here. 

• /usr/man/manl .. . man?—the unformatted version of man(l) pages. 

• /usr/man/catl ... cat7—marl ("ij pages already processed to speed access go here. 

• /usr/spool—spooled (queued) files for various programs. 

• /usr/spool/uucp—queued work files, lock files, log files, status files, and other files 
for uucp. 

• /usr/spool/cron—spooled jobs for cron and at. 

• /usr/spool/lp—control and working files for the Ip spooler go here. 

• /usr/tmp—an alternative place (to /tmp) in which to place temporary files; this 
directory is usually used when there are many files and/or the temporary files may 
be very large. 

• /usr/crontrib—contains any contributed files and commands (from user groups). 

• /usr/contrib/bin—any contributed commands are placed here. 

• /usr/contrib/lib—any contributed object libraries are placed here. 

• /usr/contrib/man—the on-line documentation for any contributed files, is placed in 
this directory. 
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Figure 3-9. HP-UX Hierarchy 
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System Startup and Shutdown 




From the time you switch on power to the computer until you have successfully logged 
in, many tasks are automatically performed by the system. These tasks include: testing 
the computer hardware, loading and initializing the operating system, communicating 
messages to the user(s), and running scheduled routines. To manage your HP-UX system 
effectively, you must understand which tasks are performed at which times. 

This chapter provides you with a description of the computer’s activities from power-up 
through successful completion of the login routine. This chapter also provides a step- 
by-step procedure for a controlled shutdown of your system. Throughout this chapter, 
you will learn about features of HP-UX that can ease your role as system administrator. 


IMPORTANT NOTE 

Always use the shutdovm command before powering down your sys¬ 
tem. If you do not you may corrupt your file system. Refer to 
‘‘Shutting Down the System” in this chapter for details. 
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System Startup Functions 

System startup is often referred to as booting the system. Booting the system is getting 
your computer from a powered down state to a functional state, where HP-UX is running 
and ready to take input. 

This section of the chapter tells how to get your system to a usable state (how to boot the 
system), and discusses the sequence of events that happens internally (what you don’t 
see on your screen, but what is happening to get your system to the usable state). 

Booting the System 

This section explains the steps you must follow to boot your system. The details of each 
step (that is, what happens internally) are discussed in later sections. 

System startup is made possible through a general-purpose piece of software called the 
boot ROM. ROM stands for Read Only Memory. It was specifically developed to support 
a wide variety of present and future Hewlett-Packard operating systems. Because differ¬ 
ent operating systems use different aspects of the boot ROM, the following description 
of the boot ROM’s operation focuses on its use with HP-UX. 

If you are unfamiliar with the Series 500 boot ROM, read the section later in this chapter 
called “The Boot ROM” before continuing. This will ensure that the correct operating 
system and system console are found during the boot procedure. 

1. Turn power on to the hard disk drive containing the HP-UX operating system. 
Wait until the disk drive is ready before continuing with the next step. (Refer to 
the operator’s manual for specifics on when your disk is ready.) 

2. Turn power on to all peripherals connected to your computer. 

3. Turn power on to your Series 500 computer. 
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The boot ROM will send messages to your screen. Figure 4-1 shows a typical 
display of boot ROM messages with an Internal Terminal Emulator (ITE) as the 
system console, on a Model 550 using an HP 98700 display system. The display 
varies depending on the version of the boot ROM. 


r 




Loader Rev 4.1 

HP-UX Model 550 Release 5.2 (97079C) 


Load done. 


Figure 4-1. Boot ROM Display 


4. Once the Load done message appears on an HP 98700 display system or on a Model 
520, the screen will clear and the following copyright messages appear. The screen 
will not clear on any other console configuration (for example, an HP 2392a termi¬ 
nal). 


r 




(c) Copyright 1983, 1984, 1987 Hewlett-Packard Company, All rights reserved, 
(c) Copyright 1979 The Regents of the Univer. of Colo., a body corporate. 

(c) Copyright 1979, 1980, 1983 The Regents of the Univer. of Cal. 

(c) Copyright 1980, 1984 AT&T Technologies. All Rights Reserved. 


The display varies depending on the version of the boot ROM, and the label placed 
on the boot area. 

The boot ROM searches for the first loadable operating system. Refer to the 
following section, “The Boot ROM Search Sequence” for information on searching 
for a loadable operating system. 

Once the operating system (HP-UX) is found, the screen will clear and a series of 
messages will appear. These messages are from the HP-UX loader. 
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The second to the last line on your screen is a message about executing fsck. 
The fsck program checks the integrity of your file system. If the program finds 
something wrong with your file system, it will try to fix it. If a problem exists in 
the root file system, fsck will attempt to fix it, reboot, then check the rest of the file 
systems. If the problem is severe, you will be instructed to run fsck interactively. 
In this case, refer to Appendix A. 

5. Log into your system. 

The system is now ready for use. 

On single-user systems or small multi-user systems, it may be useful to allow any user to 
power up the system. If this applies to your system, write a short document that describes 
the procedure for booting HP-UX (and changing system states if it applies) and distribute 
the document to all users. Knowing the specific details of your system—the hardware, 
configuration files, system states, and needs at your installation—should enable you to 
write a streamlined procedure for your users. This can ease your administration tasks 
and provide system users with more flexibility. Typically the system may be booted by 
simply turning on power to peripherals and the computer. 

Overview of Internal Functions of System Startup 

When you boot the system (described above), many things happen that you do not see 
on your screen. The “behind the scenes” startup for the typical HP-UX system follows 
these stages (each is described later): 

1. The boot ROM is started. It tests the hardware and loads an operating system. 

2. Control transfers to the HP-UX operating system. 

3. HP-UX starts a process called init. 

4. init brings the system to the default run-level, as specified by the /etc/inittab 
file. Unless you have changed your inittab file, this will be run-level 2. 

The init process also runs the /etc/bcheckrc, /etc/brc, and /etc/rc command 
scripts. 

5. init starts processes called gettys that give login prompts on terminals. 

6. A user logs in. 

There is also a mode of HP-UX, called run-level s, that can be referred to as a system 
administration mode. This mode is documented in the section called “System Adminis¬ 
tration Mode” later in this chapter. 
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The Boot ROM 

On each CS/80 and SS/80 device connected to your Series 500 is a boot area defined 
when that device was initialized. Operating systems residing in the boot area are marked 
either as “loadable” or “not loadable” with the /etc/osmark command. If you have not 
modified your system since you installed it, you will only have one operating system 
(HP-UX) residing in one boot area. 

If you are counting on the order of the operating systems found by the boot ROM’s 
search sequence (described below), make sure the mass storage device containing the 
operating system has completed its power-up cycle and is ready for use before powering 
up the computer; otherwise, the order in which the operating systems are found may be 
different. 

If the boot ROM can neither locate nor successfully load an operating system, one or 
more boot ROM error messages are issued to the system console. These errors are 
explained in the Installation Guide supplied with the computer. If no messages at all are 
displayed, suspect a hardware problem in your system. Use the procedures described in 
the installation manual to verify that a hardware problem exists before calling your HP 
Customer Engineer for service. 

The Boot ROM’s Search Sequence 

When the boot ROM searches for an operating system to load, it scans all CS/80 and 
SS/80 devices connected to your Series 500 which were successfully found in the test 
phase. HP-UX must both be marked as an operating system and as loadable code. The 
boot ROM was designed to give removable media first priority (to allow for things like 
operating system updates), and so any media loaded in a V 4 -inch data cartridge tape 
drive, removable disc pack, micro-floppy and so on, will be searched for an operating 
system. Following this, all fixed media are also searched. Lower device addresses (minor 
numbers) are searched before higher addresses. 


Note 

The removable disc pack of an HP 7935 drive is treated as remov¬ 
able media by the Rev A boot ROM; Rev B, Rev 4.0, and later 
version boot ROMs treat this as fixed media. 


According to the above priorities, external devices are searched in order of select code; a 
system at select code 4 would be found before a system at select code 5. Also, multiple 
units at the same select code and bus address are searched before moving to the next 
ascending select code or bus address. 
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To summarize, the search levels in ascending order are: 

1. device class (removable media, internal discs, external discs) 

2. select code 

3. bus address (also called device address) 

4. unit number 


HP-UX Takes Control 

c^nce tne operaiiiig sysieiii has been found and loaded successfully, many tasks 

are performed automatically by HP-UX. The first task is to search for the root file 
system. The root file system is the portion of the file system that forms the base of the 
file system hierarchy (that is, the portion of the file system on which other volumes can 
be mounted). The root file system contains the files required for HP-UX to properly run. 


The root file system can exist on any CS/80 or SS/80 mass storage medium supported 
by Series 500 HP-UX, provided that it has been marked as a root device and has at least 
16 Mbytes of storage, but this minimum size leaves little storage space for development 
work. To mark a device as the root volume, refer to the rootmark(lM) entry in the 
HP-UX Reference. If you have not modified your HP-UX system since you installed it, 
you probably won’t have to worry about rootmarking or osmarking a disk. 


Note 

The documentation which follows describes the operation of the 
system as shipped to you; however, by altering certain configura¬ 
tion or system files, any of the following procedures can change. 
If, for example, you write your own /etc/rc script, the paragraphs 
which follow may no longer apply. 
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HP-UX Starts the Init Process 

After finding the root file system, HP-UX sets up its first process, /etc/init. The 
/etc/init process becomes process one (1) and has no parent. For more information on 
processes, refer to Chapter 3. 

The init process reads a configuration file called /etc/inittab. Each line in the file 
/etc/inittab describes an activity for the system to perform when entering a given run- 
level. A run-level can be described as a set of processes allowed to run at a given time. 


After init begins, but before it makes the first transition into run-levels 0-6, all entries 
marked boot or bootwait are executed, init then executes the bcheckrc program. 

The /etc/bcheckrc (Boot CHECK Run Command) program checks to see if the system 
was properly shut down. To determine if the system was properly shut down, bcheckrc 
calls the fsclean program. You should never modify the /etc/bcheckrc file. 

f sclean checks each file system listed in /etc/checklist to see if there might be a consis¬ 
tency problem. To do this, fsclean looks at a flag called the clean byte in the superblock 
of each file system. When a file system is created, the clean byte flag is set to FS_CLEAN. 
When the file system is mounted (using the mount command), the clean byte flag is set to 
FS_OK. During a normal shutdown (that is, during execution of the reboot command), 
the clean byte is reset to FS_CLEAN. So, under normal conditions, the file system can 
be unmounted and FS_CLEAN, or mounted and FS_OK. (Refer to ‘'Shutting Down the 
System” later in this chapter for more information.) 

If, when fsclean checks the clean byte, the file system is unmounted and FS_OK, the file 
system might be in an inconsistent state. In this case, bcheckrc will run f sck automati¬ 
cally using the preen mode. This will correct most errors found. (Refer to the discussion 
on the preen mode in Appendix A of this manual. 

If the fsck command run from bcheckrc fails for any reason, bcheckrc starts a shell with 
the prompt (in bcheckrc)#, along with instructions to run fsck manually. If this occurs, 

you must run fsck to ensure the integrity of your file system. 

Some file system problems must be fixed manually because of the risk of data loss. 
When you have completed running the manual fsck, you may be instructed to reboot 
the system. If you are instructed to reboot, you must follow the instructions exactly to 
ensure the integrity of your system. If fsck does not tell you to reboot, simply exit the 
shell by typing | CTRL | D | . The bcheckrc program will then proceed. 
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Init Brings the System to Run-Level 2 

Once the booting processes have been run, init comes up in the initdefault run-level 
as defined in /etc/inittab. The initdefault run-level is run-level 2 (as shipped). If 
initdefault is not specified, init will prompt the user for a value when the system reaches 
this point. Refer to the init{lM) and intttab{4) entries in the HP-UX Reference for more 
information. 

Each time init changes run-level, either at boot time or when invoked manually, 
/etc/inittab is read. After reading /etc/inittab and signalling processes as required, a 
line in /etc/inittab invokes /etc/rc. 

A file called /etc/mnttab contains a list of mounted file systems. This file is removed at 
boot time and during a system shutdown. The /etc/rc script checks for the existence of 
/etc/mnttab to determine whether to perform system initialization and to start various 
daemon (background) processes. 

Invoking /etc/rc 

Whenever /etc/rc is invoked, the /etc/rc script sets the environment variables PATH 
(the default search path that the system uses to find commands) and TZ (for time zone), 
/etc/rc next exports the TZ variable (using the export command). Exporting TZ causes 
rc (and any child process of rc) to override the default time zone (EST7ETD); for more 
information, refer to the ctime{3C) entry in the HP-UX Reference manual. 

Next, the system console is set up and initialized with the stty command to set such 
attributes as the baud rate, communications protocol, and tab settings. 

Contents of /etc/rc 

You may customize /etc/rc to perform functions which you wish to occur every time the 
system is booted or whenever there is a change in run-level which init does not handle. 
As shipped, the /etc/rc shell script: 

• Mounts the file systems configured in /etc/checklist (refer to checklist{4) in the 
HP-UX Reference). 

• Sets the host name. This is used by various networking processes. 

• Executes the /etc/cron program if it exists on your system. 

cron executes commands at specific dates and times according to the instructions 
submitted by the crontab command (refer to crontah{i)). 
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You may want to add entries using the crontab command to automatically and 
periodically perform procedures such as: 

• Backing up the system. 

• Calling other HP-UX systems for mail and other uucp transactions. 

• Executing system accounting commands (refer to Chapter 6). 

• Starts the line printer spooling system if you have set it up on your system. 

• Preserves editor files (if they exist). 

• Removes some temporary files that are no longer needed by the system. 

• Starts UUCP if it is set up on your system. 

• Saves various logging files (by renaming them) and prints revision information about 
the HP-UX operating system software. 

Init Spawns gettys to Cause a Login Prompt 

Once /etc/rc has finished its run-level 2 execution, control returns to /etc/init which 
now executes the commands from the command field of all run-level 2 entries in 
/etc/inittab. Typically, /etc/inittab’s run-level 2 command field entries consist of 
/etc/getty commands, one for each terminal on which users are to log in. This sets up, 
on each terminal, the process that runs the login program and eventually runs the shell 
program once someone successfully logs in. 

The /etc/inittab entries are of the form: 
id:rstate:action:process 

where id is a unique two-character identification code, rstate, specifies the run-levels 
to which this entry applies, action tells init what to do with the entry, and process is 
an HP-UX command to execute. Run-levels are described in inittab[A) of the HP-UX 
Reference. 
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The action respawn tells init to continuously re-create a getty process at the console 
in the specified run-levels. Leaving the rstate field empty (as shown below) will cause 
execution in all run-levels (0 through 6). The example below sets up a getty process for 
the console in all possible run-levels: 

CO::respawn:/etc/getty console H 

As shipped to you, /etc/getty is invoked only for the system console in run-level 2. You 
will need to customize your system by adding additional gettys to /etc/inittab for each 
terminal supported by your system. (Refer to “Adding Peripheral Devices” in Chapter 
5 for more information.) 

The /etc/getty command is the first command executed for each login terminal. It 
specifies the location of the terminal and its default communication protocol, as defined 
in the /etc/gettydef s file. It prints the /etc/issue file (if present) and it causes the first 
login: prompt to be displayed. Eventually, the getty process is replaced by your shell’s 
process (refer to the following section, “A User Logs In”). 

When that process is terminated (when you log out), the /etc/init process is signalled 
and takes control again, init then checks /etc/inittab to see if the process that signalled 
it is flagged as continuous (“respawn”) in the inittab entry. If the process is continually 
respawned, init again invokes the command in the command field of the appropriate 
inittab entry as described above (that is, the getty runs and a new login: prompt 
appears). If the process is not flagged as continuous, it is not restarted. 


Note 

Do not add /etc/getty entries to /etc/inittab for terminals which 
are not present. If you do, the getty process will repeatedly send 
an error message to the console, wait 20 seconds, and then exit. 
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A User Logs In 

The tutorials supplied with your system describe how to log in (gain access to the system). 
This section describes the function of the operating system during that process. 

1. The login process begins when you type in a user name in response to the login: 
prompt. Once the user name has been entered, /etc/getty executes the login 
program with the user name as an argument; /bin/login checks the name against 
the list of valid user names kept in /etc/passwd. 

2. If the user name is valid, login checks to see if there is a password associated 
with the user name (the encrypted form of the password is stored in /etc/passwd). 
If there is a password associated with the user name, the system prompts for a 
password. The password typed in is encrypted and compared to the encrypted 
password stored in /etc/passwd. If a valid user name is entered and that name has 
no password associated with it, the user is logged in without further prompting. 

For security reasons, if the user name entered is invalid (it is not found in 
/etc/passwd), the system still prompts for a password before denying access to 
the system. This makes it more difficult for an intruder to find and use a valid 
user name. Once access is denied, login displays its login: prompt and waits for 
another user name to be entered. 

If you wish to keep track of all bad login attempts, create a log file called /etc/btmp 
by entering (while the root user): 

touch /etc/btmp 

If this file exists, the system uses it to log unsuccessful login attempts. You can 
read this file (using the lastb program) to help determine if unauthorized users are 
attempting to login. 

The system also keeps track of all successful logins and logouts in a log file called 
/etc/wtmp. If this file is created, you can look at the login and logout information 
using the last command. 

3. The login process sets numeric user and group IDs. The values are taken from the 
values supplied in the user ID and group ID fields of the /etc/passwd file. 

4. The login process sets the current working directory to that supplied in the home 
directory field in /etc/passwd. 
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5. The login process executes (using the exec system call) whatever command is 
present in the command field of your /etc/passwd entry. Any command may be 
placed in the command field of /etc/passwd. Typically, the command invokes a 
shell for the user. The most common shells are /bin/sh and /bin/csh. If no entry 
exists in the /etc/passwd command field, /bin/sh is executed by default. 

You may wish to execute an application program for the user. This is advisable 
when the user has no knowledge of HP-UX and only wants to use the system to run 
a specific application. For example, suppose that an inexperienced user wants to 
access HP-UX only to run the program testx (a program written by your company 
that tests widgets). The program is contained in his login directory. You might 
add an entry to /etc/passwd of the form: 

j ohn::135:12::/users/ j ohn:/users/ j ohn/testx 

The name John is the user’s login name and the values 135 and 12 are his user ID 
and group ID, respectively. The next entry (between two colons) is reserved for 
future use. You can use this field for comments. The entry /users/John is the user’s 
login directory. The last entry is the command field; it specifies that when the user 
logs in, the program /users/j ohn/testx is automatically run (instead of a shell). 
In this example, after the user John finishes executing the program testx, he will 
automatically be logged off the system. 

The same thing happens in the more common case of a user executing a shell: when 
the shell is terminated with a I CTRL | D | or an exit command, the user is logged 
off. 

The command field of /etc/passwd is also useful for enabling a user to access in¬ 
formation without logging onto the system. For example, the system is shipped 
with a passwd entry containing the user name who with the command /bin/who in 
the entry’s command field. Supplying who in response to the login prompt causes 
a list of all system users (all users currently logged in including the user who) to be 
displayed on the terminal. The user is logged in only for the duration of the who 
program and is logged off when the program terminates. This login lets anyone 
determine a valid login name; you may wish to delete this entry to provide more 
security. 

As shipped to you, /etc/passwd has entries for the users who (used as described 
above), date (which executes the date command providing handy access to the 
time and date), and sync (which executes the sync command). The sync command 
writes all the information contained in the system’s I/O buffers (in RAM) to the 
disk. 
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6. Assuming a shell was generated in step 5, the shell now executes the system shell 
script. The system shell script sets up a user’s environment. The possible system 
shell scripts are: 

• /etc/profile for the Bourne shell (/bin/sh) and for the restricted shell 
(/bin/rsh) 

• /etc/csh. login for the Berkeley C shell (/bin/csh) 


As shipped to you, these scripts define and export the environment variables PATH, 
TZ, and TERM. Since /etc/profile and /etc/csh.login execute for each user as 
he logs in and since the super-user (root) owns these scripts, you (as system admin¬ 
istrator) can modify /etc/profile and /etc/csh.login to change and export each 
user’s default settings for the environment variables. This is ideal for forcing the 
execution of commands that each user should execute at login. 

For example, /etc/profile and /etc/csh. login (as shipped to you) assume that 
/etc/motd (message-of-the-day) contains one or more messages and sends the con¬ 
tents of that file to each user’s terminal at login (via the cat command; the output 
appears on the user’s standard output). To change the message sent to each user, 
simply edit /etc/motd. 

Edit /etc/profile and /etc/csh.login when you want to alter their function. New 
commands can be added to these scripts; old commands can be removed or modi¬ 
fied. Changes made to these scripts do not go into effect until the script is executed. 
The script is executed automatically at login. 

7. /etc/profile executes the stty command (for the C shell, .login executes the tset 
command) to set a terminal’s characteristics. In addition, they define the path for 
the MAIL environment variable and they perform the following tasks: 

• Display the message-of-the-day (contained in /etc/motd). 

• Use mail -e to detect if any mail is present; if there is any mail, the message 
You have mail, is displayed. 

• Execute news -n which displays the names of all new files added to /usr/news 
since the last time news was read. 
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8. The shell executes the user’s local environment script if it exists in the user’s home 
(login) directory (note the prefix which normally makes these hidden files): 

• .profile (for the Bourne shell), 

• .login (for the C shell), 


Typically, the local environment file is created by the system administrator for 
each user. Users may customize their local environment on the HP-UX system by 
modifying the local environment file. Typically, a user uses the local environment 
file to: 

• Set and export (with the export command) environment variables such as 
shell prompts (PSl and PS2) and the default search path (PATH). In the 
Bourne shell variables must be exported to have an effect upon subsequent 
processes. In the C shell, you must use setenv. 

• Execute commands at login (for example, the who command, to see who else 
is on the system and the is command to list the names of files in the login 
directory). 

• Set terminal options with the tset command. 


In addition to executing . login, the C shell also executes the file . cshrc (if it exists) 
each time a new C shell starts. Many programs (such as vi) allow you to start a 
shell from within the command. This is called a shell escape, .chsrc would be 
re-run for a shell escape, .login is executed following the execution of .cshrc. 

9. Now that you have successfully logged in, the shell prints a prompt and waits for 
your first command. 
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System Administration Mode 

In addition to the normal run-level (run-level 2), HP-UX comes with a system adminis¬ 
tration mode: run-level s. If the initdefauit entry in /etc/inittab is s, then immediately 
you will get a Bourne shell at the console, logged in as root. The bootwait and boot en¬ 
tries in /etc/bcheckrc and /etc/brc are not executed. In this run-level no gettys are 
issued, nor are any actions taken by the script /etc/rc. Additionally, bcheckrc and fsck 
do not get executed. 

Run-level s is a system maintenance run-level. When you shut down your system, you will 
be in run-level s. Other than during system shutdown, run-level s is not recommended 
by Hewlett-Packard since certain processes that monitor and check your system do not 
run in run-level s. 

Booting Problems 

Booting HP-UX (bringing up the system) should be a straight-forward process. However, 
in case of any difficulties, the following helpful suggestions are provided: 

• If for any reason, the boot ROM is unable to find and load an operating system, 
informational and/or error messages are displayed on the system console. Refer to 
Appendix B in this manual. 

• Remember that the mass storage device containing the HP-UX system must be 
powered up and have achieved a ready state before powering up your Series 500 
computer. If the disk drive has not completed its power-up sequence (which may 
require several minutes on some disk drives), the boot ROM will not be able to 
access the disk and load the system. 

• The boot ROM follows a specific search for the system console. 

• The /etc/bcheckrc script executes the fsck -P command at bootup to check the file 
systems when the system was incorrectly shutdown. The file system consistency 
check program (fsck) is vital to the maintenance of your file system. If the file 
system becomes corrupt (whatever the cause), continuing to use the corrupted file 
system invites disaster. For this reason, if fsck finds serious file system errors it 
will prompt you to re-run fsck interactively. Since it is the /etc/bcheckrc program 
prompting you, you will see the prompt: 

(in bcheckrc)# 

You must run fsck on the corrupt file system to correct the errors. Refer to Ap¬ 
pendix A, “Using the fsck Command”, in this manual for details on checking the 
file systems. 
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Shutting Down the System 

Improperly powering down the computer (or an “on-line” mass storage device) can cause 
the file system to become corrupt. The shutdown command terminates, in an orderly 
and cautious manner, all processes currently running on the system. This allows you to 
power down the system hardware without adversely affecting the file system. 

The shutdown command kills all unnecessary processes, forces the contents of the file 
system’s I/O buffers to be written to the disk (with the sync command), unmounts 
any mounted disks listed in /etc/checklist, removes the /etc/mnttab file, and takes the 
system into the system administration mode (run-level s). It also will optionally halt or 
reboot the system. 

To shutdown the system from a normal operating mode, perform the following steps: 

1. Login as the super-user root. 

2. Move to the root directory of the file system by entering the command: 

cd / 

3. Execute the shutdown command. 

The shutdown command allows you to specify a grace_period, which is the number 
of seconds you want shutdown to wait before terminating all processes. Note that if 
you have users on your system you should never shut down the system with a grace 
period of 0. You can also use the -r option to automatically reboot the system 
after reaching run-level s, or the -h option to halt the system. 

The shutdown command looks like this: 

/etc/shutdown [-r I -h] grace_period 

The -r option shuts down the system and automatically reboots the system. The 
-h option shuts down, and halts, the system. This is used for powering down the 
computer. If you do not specify any options you will be placed in run-level s, the 
system administration mode. 

If grace_period is non-zero, shutdown prompts to see whether you wish to send the 
standard broadcast message or enter your own message. If you elect to send your 
own broadcast message, type the message on the terminal. When you are finished 
typing the message, press | Return | . Then press and hold the | CTRL | key as you press 
I D I to signify the end of the message. 
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If grace_period is omitted, then after waiting 60 seconds, shutdown asks if you want 
to continue. When shutdown completes its task, it displays a message telling you to 
halt the system when you are ready. 

4. If you executed shutdown -h, the system will halt, printing a message on the system 
console that says '‘halted”. You may now power down the system. The only way 
to reboot after halting is to cycle power on the system. 

If you have not executed shutdown -h, you did not halt the system. If you wish to 
power down the system, you can halt the system by typing in: 

reboot -h 

5. If you do not wish to power down the system and have not halted the system, you 
can now perform system maintenance. When you are finished and need to resume 
normal operating run-level, you should type in: 

reboot 


Examples: 

• To activate a newly configured kernel you should shut down the system and auto¬ 
matically reboot: 

shutdown -r grace_period 

This shuts down the system after grace^period seconds, then reboots the same 
operating system you are currently running. 

• If you wish to install an interface card, you must turn power off to your computer. 
Halt the system by typing (note that this command line has a grace period of 0): 

shutdown -h 0 

Wait for the halted message, then turn the power off to the computer. 
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• If you wish to backup your system after giving your users two minutes to log off, 
you should change to run-level s by typing: 

shutdown 120 

After running backup, bring the system back up with all the daemons running by 
typing: 

reboot 

• If you wish to halt the system from run-level s with no daemons or programs 
running, type: 

reboot -h 


Note 

The shutdown command does not address NS or ARPA/BSD net¬ 
working. To understand how to shutdown the system when net¬ 
working is involved, refer to your networking manuals. 
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Power Fail or Disk Crash Recovery 

Since you have invested a significant amount of time instaiiing HP-UX and creating 
file systems, it is important to maintain the file system to ensure its integrity for your 
users. Simple daily checks and procedures and correcting problems before they become 
catastrophic will save you from remaking the entire system. Backup procedures are 
discussed in Chapter 5, the section “Backing Up and Restoring the File System”. If 
these procedures are followed on a regular basis, a power failure or disk crash should not 
be catastrophic. 

Likewise, during installation of HP-UX, you were encouraged to create a recovery system. 
The recovery system will be very important if your system problems are serious enough 
that the normal system will not even boot. Details on creating and using a recovery 
system are contained in Chapter 5 of this manual. Unless your disk has already crashed, 

it is not too late to create a recovery system right now. Take the time for this very 
important procedure. 

If your electricity goes off or if you accidently pull the plug on your Series 500, the 
computer simply stops. However, because the system was not shut down using the 
shutdown or reboot command, fsck will run during the next bootup. 

If your hard disk crashes or the power fails, then try to boot and run fsck. (Refer to 
Appendix A and to this chapter, the section “HP-UX Starts the Init Process”.) If you 
can’t boot, use your recovery system. If none of the above work, then call your HP 
support engineer or re-install and restore your system from backups. 
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Notes 
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The System Administrator’s Toolbox 

Organized alphabetically by task or procedure, this chapter is designed to guide you 
through your designated tasks as the system administrator. Each major heading in the 
chapter identifies one or more administrative tasks. The procedure supplies at least one 
method for achieving the stated task. The following topics are covered (refer to the Table 
of Contents for the page number): 

• Adding/Moving Peripheral Devices 

• Adding/Removing Users 

• Adding to /etc/checklist 

• Backing up and Restoring the File System 

• Changing a Password 

• Changing and Creating System States 

• Changing HP-UX Environment Files 

• Communicating with System Users 

• Configuring HP-UX 

• Controlling Disk Use 

• Creating File Systems 

• Creating Groups/Changing Group Membership 

• Creating a Recovery System 

• Media Utilities 

• Modifying the Boot Area 

• Mounting and Unmounting Volumes 

• New Naming Conventions for Device Files 

• Removing Optional Products and Filesets 

• Setting the System Clock 
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• Setting Up the LP Spooler 

• Updating HP-UX and Installing Optional Products 

• Using Optinstall to Install Optional Products 
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Adding/Moving Peripheral Devices 

The HP-UX operating system requires the existence of device hies to perform I/O to 
peripheral devices, such as disk drives, printers, tape drives, and terminals. Device files 
and an associated topic, block and character I/O, are discussed in the “Concepts” chapter 
of this manual. This section introduces you to the tools necessary to set up peripherals 
and create their associated device files. The section also discusses terminal hardware 
configuration and the HP-UX modifications required for communicating with terminals. 

During the system installation process, a number of device files were created on your 
disk. If you have a fairly simple single- or multi-user system, the supplied set of device 
files may be all that you need. If, however, your system is a large or complex one (with 
many peripheral devices), you will need to create additional device files to communicate 
with those devices. You may also want to create new device files or change existing ones 
if you decide to add or remove particular peripherals at some later date, or if you find it 
necessary to tune your system by changing the locations (interfaces or bus addresses) of 
peripherals. 

The default set installed with your system contains device files for the system console 
and device files that are used and required by HP-UX to communicate with some pseudo¬ 
devices; that is, hardware not considered to be peripherals but that requires device files 
for system communication (such as /dev/tty). These latter files must not be removed 
from the system under any circumstances, if HP-UX is to operate properly. 

To see all of the currently installed device files on your system, log in on the system and 
type: 

11 -R /dev 

The system will respond by listing all the files under the /dev directory. The listing should 
include all of the files shown in Table 5-1. The table also includes brief explanations of 
the devices associated with these files and other useful information. 
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Table 5-1. Default Device Files 


Device 

c/b 

Major 

Minor 

Notes 

console 

c 

31^ 

OxScAdOO 

System message port 

syscon 

c 

31^ 

OxScAdOO 

System console (linked to console) 

systty 

c 

31^ 

OxScAdOO 

System tty (linked to console) 

tty 

c 

20 

0x010000 

Process group control terminal 

null 

c 

15 

0x000000 

Null file (“bit bucket”) 


Before delving into the software aspects of adding/moving peripheral devices, be sure 
your peripheral hardware is set up correctly. The guidelines given in the Installation 
Guide supplied with your computer will help you configure your hardware. Make sure 
tliai you gracefully shut down your system before you change any of the address switches 
on your peripherals. To shut down the system, type: 

/etc/shutdown -h 

For details on shutdown, see the section “Shutting Down the System” in this chapter. 

Overview of the Task 

There are several basic steps required to add or move peripheral devices to your system. 
Here is an overview of the tasks you will need to accomplish; they are explained in detail 
later: 

1. Using the guidelines covered in the Installation Guide supplied with your computer 
and the installation manual supplied with the peripheral device, determine the best 
place (in terms of HP-IB Bus Addresses, shared sets of I/O resources, expected 
usage, etc.) to locate the peripheral. 

2. Connect the peripheral device. If the peripheral device requires an interface card, 
set the appropriate switches on the card and install the card in the computer. Never 
install an interface card while the computer is powered up. Then set any required 
switches on the device and connect it to the computer (or interface card). If you 
ever change the switch settings on an HP-IB device, be sure to power cycle the 
device before attempting to address it. 


^ Use major number 31 for consoles attached to the HP 27128 or HP 27130 interface cards and major 
number 29 for all others. 


114 The System Administrator’s Toolbox 














3. Ascertain whether the peripheral device will be addressed as a block or character 
device, or both (disk drives will require both modes of access). Block and character 
I/O are discussed in the “Concepts” chapter in this manual, and examples are 
provided later in this section. 

4. Next, determine if the device file necessary to communicate with the peripheral 
device already exists on your HP-UX system. Some device files were shipped with 
your system and are shown in the table above. Default files reside in the /dev 
directory and follow the naming conventions explained in the intro (7) entry in the 
HP-UX Reference manual. 

5. If the appropriate device file does not exist for the device in question,, you will 
have to create one. There are two ways to create device files — using the mknod 
command to create a particular device file or editing, then executing the mkdev 
shell script to create one or more device files. Your choice of which method to use 
depends on how many device files you need to create and how experienced you are 
at the process of creating them. Use the mkdev script or the tables given later in 
this section to get the parameters (major and minor numbers) needed by mknod to 
create the device files. 

Determining the Peripheral’s Location 

If the peripheral you wish to add/move is an HP-IB device, determine the select code 
and bus address where the device will reside. The Installation Guide supplied with your 
computer lists several guidelines to help you identify an appropriate location for your 
HP-IB peripheral. The guidelines for interface selection are reviewed here; you should 
still consult your Installation Guide to determine all available HP-IB bus addresses for 
devices on these interfaces. 

• The system root device is usually located at select code 5 on a high-speed 
HP 27110A or HP 27110B interface card. 

• The system printer (if present) should be on a medium- or low-speed HP-IB inter¬ 
face, separate from the system root device. 

• A 9-track tape (if present) should be placed on a low-speed HP-IB. 

• Avoid putting flexible disk drives on the same interface as the root device. 

• Disks other than the root device should be placed on a separate HP-IB bus when 
possible. 

• Graphics devices should be placed on low-speed HP-IB interfaces when possible. 

• If you have an HP 98288A Display Station Buffer (DSB) board with a model 550, it 
must be installed in main processor board slots 4, 5, 6, or 7 by your HP Customer 
Engineer. This is usually bundled with the HP 98700H display station system. 
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Connecting the Peripheral 

Connect the peripheral to your computer at the location you have just determined. The 
computer’s Installation Guide provides instructions for installing an interface card and 
identifying its select code. The manual supplied with the peripheral details the procedure 
for connecting it to the computer and setting its address if it has one. 

Terminal hardware configuration is covered in the computer’s Installation Guide. You 
must create the associated device files for the terminal as well as follow the instructions 
at the end of this section to set up the software aspects of terminal configuration. 


CAUTION 

Do not attempt to unpack and connect a CS/80 disk drive (other 
than the HP 7908) yourself. The CS/80 disk drives are packed 
to prevent damage during shipment. To prevent damage to the 
device, an HP Customer Engineer must unpack, install and test 
the device. 


Block versus Character Device Files 

Determine whether you should create a block device file or a character device file. Block 
device files are used for communicating with disk mass storage devices that are to be used 
for mountable file systems. Block device files are also used for mounting a file system 
from a supported cartridge tape drive. However, mounting a file system from a cartridge 
tape drive is NOT a recommended procedure due to excessive wear on both the tape 
drive and the tape medium. 

Character device files are used for communicating with terminals, printers, plotters, 
digitizers, magnetic tape drives, and, on occasion, disk mass storage devices. Communi¬ 
cating with a mass storage device (such as a disk) with a character device file causes the 
system to treat the disk like a magnetic tape drive (see the disk(7) entry in the HP-UX 
Reference) and the “Concepts” chapter of this manual. If you are going to use the tar, 
tcio, cpio or dd commands to write to tape, you will need a character device file. 

In most cases, disks should have both block and character device file entries. All other 
devices should have only character device files. 
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Creating Device Files 

If, by examining the entries in the dev directory, you have determined that the appropriate 
device file for the peripheral does not already exist, you must create one. Device files 
are created with the mkdev script or, alternatively, with the mknod command, mkdev is 
a shell script that uses the mknod command to create one or more device files; it allows 
you to create device files for every allowable address and device combination. It is also 
a source of information for parameters that you need to execute the mknod command. 
Those parameters are also given in tables later in this section. Before using mkdev, you 
must customize it (by editing the file) to select the device files to be created and to adjust 
their associated parameters. 

The remainder of this subsection explains how to use the mknod command to create 
device files. While reading the remainder of this material, you may find it handy to have 
available a copy of /etc/mkdev. 

To create a device file with the mknod command, you need to login as root and make an 
entry of the form: 

/etc/mknod path_name file^type major minor 

where path^name is the pathname of the device file to be created. You should select 
a file name for the device file which easily identifies the associated peripheral. The 
entry intro(7) in the HP-UX Reference manual describes a naming convention for device 
files. Using this naming convention makes your system easier to support and maintain. 
Device files are kept in the directory /dev for ease of housekeeping. Additionally, many 
commands expect to find device files in /dev and will fail if the required device file is not 
there. 

file_type is a single character b, c, n or p; b specifies that the file is a block device file, c 
specifies that the file is a character device file, n specifies that the file is a network device 
file and p specifies that the file is a named pipe. See mknod(lM) for making network 
device files. 

major is the number of the kernel driver used to communicate with the peripheral. A 
table of all major numbers is provided later in this section. 

minor is a value specifying the actual address on the I/O bus. The minor number is 
made up of the select code, bus address, unit and volume numbers. The parts of the 
minor number are described in more detail in each device’s section. 
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Be aware that the mkdev command automatically handles other aspects of the creation 
process besides executing mknod commands. These aspects include setting up the correct 
access modes on device files. 

If you choose to use the mknod command (instead of modifying, then executing the mkdev 
script), determine the needed major parameters from the tables given later in this section. 
Follow the guidelines in the ‘‘Setting Appropriate Permission Masks” section to insure 
that correct access modes are set on the device files you create. 

Using the mkdev Script 

Before using mkdev, first make a copy of the file /etc/mkdev for archival purposes by 
typing: 

cp /etc/mkdev /etc/mkdev.old 

Now that you have saved an untouched version of the command (the file /etc/mkdev. old), 
you can use any of the HP-UX text editors to edit the “working version” of the script 
(the file /etc/mkdev). Customize it by following the instructions below and by using the 
detailed comments contained in the script. The commented script itself is a good source 
of information. Be certain the changes you make do not defeat the script. 


Note 

You must edit and customize the /etc/mkdev file before using it. 


After you have modified the file, you can execute the script by logging in as root and 
typing: 

/etc/mkdev 

Alternatively, you can save the informative and diagnostic messages produced by the 
script for later examination. This is accomplished by redirecting a copy of the output to 
a file, as well as the screen. To redirect output to a log file, type: 

/etc/mkdev I tee log^file 

where log^file is the path name of the file where you wish to receive diagnostics. 
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After you have executed the mkdev script, you can examine the results by typing: 

11 -R /dev 

This “long” listing gives you information about all of the parameters that were used to 
create the device file. For example, you should see an entry similar to the following: 

crw--w--w- 1 root other 31 0x000000 May 20 09:30 console 

The first character in the entry tells you whether the device file is a character (c) or 
block (b) device and the next series of characters represent the file’s access permissions. 
The major and minor numbers are the two numbers contained in the size field, in this 
case 31 and 0x000000 respectively (refer to the ls(l) entry in the HP-UX Reference). 

If you make a mistake, delete the device files you wish to change and re-create them 
by editing and executing the mkdev script again. You should be aware, however, that 
deleting some of the default device files contained in /dev will cause severe problems 
because the system needs these files to operate properly. For example, you will not be 
able to access your root device if you delete its device file. 

Editing the mkdev Script 

The mkdev script contains a series of mknod “templates” for creating every allowable de¬ 
vice/address combination. They are called templates because they are models that must 
be modified to reflect the actual parameters you want associated with the peripheral’s 
device file. 

The script is organized into device classes. Separate sections and templates exist for: 
miscellaneous devices, terminals, CS/80 mass storage devices, non-CS/80 mass storage 
devices, magnetic (9-track) tape devices, printers, general HP-IB devices (plotters, digi¬ 
tizers, graphics printers, etc.), and CRT graphics devices. 

Begin with reading the first few pages in the script. These pages describe the overall 
structure of the script and tell you how to modify it. Then determine what device class 
a peripheral belongs in and read the information in the script and in the sections that 
follow. 
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Before modifying the script, be sure that you have created an archive copy as described 
earlier. In general, modifying the mkdev script consists of the following steps: 

1. Comment out the lines that read: 

echo "mkdev: template version -- customize script before using it" 
exit 1 

by adding a comment sign (the # character) in front of each line. These lines 
indicate your intent to run a modified script. The script will not create any device 
files if you do not eliminate these lines. 

2. Find the template or device class that corresponds to the peripheral. 

3. Read the script’s instructions pertaining to that device class. 

4. Decide what name to use for the device file associated with the device. 

5. Copy the mknod template if indicated by the instructions. 

6. Modify the mknod template to correspond to the name you chose. Use the intro(7) 
naming convention or one of your own. 

7. Fill in any of the template’s missing parameters (or placeholders for parameters) 
where the instructions indicate; this includes the major and minor numbers for 
some device classes. 

8. Remove the comment sign in front of the modified template so the line will be 
executed when you run the script. 

Using mknod with the Supplied Tables 

The following sections are structured by “device class” and contain the information 
and tables you need to create device files using mknod. These device class sections are 
sequenced just as in the mkdev script. 

Each line in the tables (supplied in each device class section) corresponds to either one 
or two device files; two if the “raw” device entry is given on the same line as the regular 
entry. These tables use the following representation: 

• The Device column represents either the literal name of a device file or a symbolic 
name. If not obvious from context, the section specifies whether the name is literal 
or symbolic. 

• The C/B column specifies Character or Blocked access. 
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• The Major and Minor columns specify the major and minor parameters to be used 
with mknod. 

® There may also be a column for suggested pathnames or notes. The Notes column 
contains commentary for your information only and should never be entered as part 
of a mknod command. Under no circumstances should you change any table entries 
flagged as: Mandatory (do not change). 

The rest of the “Adding/Moving Peripheral Devices” section contains: 

• A table of all major numbers for each supported device class. 

• Guidelines for setting “permission masks” to insure appropriate ownership of and 
access to device files. 

• Specifics on Miscellaneous Devices. 

• Specifics on Terminals and Modems. 

• Specifics on Consoles. 

• Specifics on Pseudo Terminals (pty’s). 

• Specifics on CS/80 Hard Disks and Cartridge Tapes. 

• Specifics on Magnetic Tape Devices. 

• Specifics on Printers. 

• Specifics on Plotters and Digitizers. 

Table 5-2 shows the major numbers (numbers you need to use in the mknod command) 
for each supported device class. The specific tables in each of the following sections also 
contain the applicable major numbers. 
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Table 5-2. Major Numbers for Device Classes 


Major 

Device Class 

1 

All CS/80 type mass storage devices. 

6^ 

8-inch HP 9895 flexible disk drives. 

8^ 

5V4-inch HP 8290X flexible disk drives. 

9^ 

HP9885M/S flexible disk drives. 

10^ 

Memory disk configured by sdf init. 

11^ 

HP 7970 magnetic tape drive. 

12 

HP-IB devices, except CS/80 mass storage, CIPER protocol printers, 
or laser printers. 

14^ 

CIPER protocol printers. 

15 

Null device. 

18^ 

HP27112A GP-IO interface card. 

19^ 

Raw transfer to ASI or 8-channel MUX interface cards (see 31). 

20 

/dev/tty 

22 

Cooked output for HP 2631 type printers. 

26 

Raw format for the Model 520’s built-in thermal printer. 

28^ 

Models 520B and 520(^ graphics displays. 

29^ 

Model 520 built-in console, HP 98700 console, 6-channel modem MUX, 
and the slave side of a pty. 

31^ 

Normal ASI and 8-channel MUX interface cards. 

32^ 

Model 520 standard color display and the HP 97062 color output in¬ 
terface. 

33'^ 

SRM (Shared Resource Manager) interface. 

34^ 

HP 2285 EtherNet interface. 

352 

HP 2680 and HP 2688 laser printers (not HP 2686). 

36^ 

HP 7974 and HP 7978 magnetic tape drivers. 
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Table 5-2. Major Numbers for Device Classes (Cont.) 


Major 

Device Class 

37^ 

Model 550 internal HP-IB. 

38^ 

HP 27125 EtherNet interface. 

39^ 

HP 27125 IEEE 802 interface. 

40^ 

HP 2285 IEEE 802 interface (see 34). 

4P 

HP 98700 raw 8042 HP-HIL. 

42^ 

HP 98700 HP-HIL devices. 

43^ 

ITE (internal keyboard emulator) keyboard. 

45^ 

Master side of a pty (see 29). 


Setting Appropriate Permission Masks 

Each device-class-specific section in the mkdev script shows a permission mask. If you use 
the mknod command instead of the mkdev script, make sure that permission masks and a 
few other items (automatically handled by the mkdev script) are properly set up. 

You can do this by setting the appropriate protection mask for the device class you are 
creating before creating the device, or by creating the device file, then performing a 
chmod on the file. 

The mkdev script sets up two permission masks: 

defumask=lll 

restrictedumask=166 

In the script each device class section has one or more lines such as: 

umask $defumask 
or 

umask Srestrictedumask 

When not using the mkdev script, you must use the correct permission mask so the device 
file(s) will have correct access permissions. 


^ This is an optionally installed driver. See the section on installing optional products which follows in 
this chapter. 

^ This driver accesses optionally installed system segments see the section on Modifying the Boot Area 
in this chapter. 

This driver is optional if the root disk is not on the internal HP-IB card. However, if the root disk is on 
the internal HP-IB, then this driver is required. 
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Miscellaneous Devices 

The device files associated with the miscellaneous device class are precisely those default 
device files that the system needs in order to run properly. Each HP-UX installation must 
have the device files /dev/null, /dev/console, and /dev/tty. The device file /dev/null is 
a null file (a “bit bucket”) used by many HP-UX commands. The device file /dev/console 
identifies the system console and the device file /dev/tty is a synonym for the control 
terminal associated with a process group. 

These miscellaneous device files are copied to your system when HP-UX is installed. They 
should not be changed or modified. If one or more of these files is accidentally deleted 
or otherwise destroyed, you can recreate it by editing the mkdev script and removing the 
comment sign (the # character) from in front of the corresponding entry. Alternatively, 
recreate it with the mknod command using the character/blocked designation, major, and 
minor numbers given below. 

Three default device files are shown in Table 5-3. If you need to recreate them, you must 
use umask 111 before executing the mknod command. 

Table 5-3. Default Device Files 


Device 

c/b 

Major 

Minor 

Notes 

console 

c 

31 

0 x000000 

Mandatory (do not change) 

tty 

c 

20 

0 x010000 

Mandatory (do not change) 

null 

c 

15 

0 x000000 

Mandatory (do not change) 


For example, to recreate the device file for the null device, log in as the user root and 
type the following lines (each followed by | Return | ): 

cd /dev 

/etc/mknod null c 15 0x000000 

There needs to be a /dev/systty (which is linked to /dev/console), and a /dev/syscon 
(which is linked to some terminal- usually the console). This is explained in init(lM). 
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Memory Volumes 

Creating a device file using driver number 10 enables you to treat a portion of your 
computer’s RAM as if it were a disk device. Once a memory “disk” has been created, 
it may be treated just as any disk device. It can be mounted, for instance, or used 
to contain a boot area. It can also be used to test procedures which access a disk 
frequently, enabling you to avoid disk delays during testing. One obvious difference is, 
since a memory volume is made up of RAM, it cannot survive a system power-down. 

Table 5-4. Treating RAM as a Disk Device 



Suggested 

Pathname 

C/B 

Major 

Minor 

Raw Memory Volume 

/dev/rmdU 

c 

10 

OxOOOOUO 

Block Memory Volume 

/dev/mdU 

b 

10 

OxOOOOUO 


When creating a device file for a memory “disk”, the select code, bus address, and volume 
number parameters are ignored. The hexadecimal unit number is used to create multiple 
memory “disks” (a maximum of 16 “disks” are allowed). For example, the command: 

/etc/mknod /dev/rmdc c 10 OxOOOOcO 

creates a character device file called /dev/rmdc, which can now be used to communicate 
with a portion of your computer’s RAM as if it were a disk. The amount of RAM allocated 
to a particular memory volume is set by the interleave parameter of sdfinit. This 
number is specified in 512-byte blocks. 2047 is the largest number of blocks (“sectors”) 
you can specify. Using 0 will destroy the volume. Note that memory allocated to a 
memory volume is not virtual, and thus is unavailable for any other use. A memory 
volume must be initialized before it can be used. 

To de-allocate RAM from a memory volume and return it to the system, re-initialize the 
memory volume (using sdfinit with a blocksize, bootsize, and interleave of zero), as in: 

sdfinit /dev/rmdc 000 
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Terminals and Modems 


Communication ports user terminals as well as modems need to be identified by 
one or more device files, depending on the intended use of the port. Device ttyd files are 
required for ports that receive incoming signals (‘‘dial in” modems); tty files are required 
for terminals (hard-wired ports). Ports that transmit signals (“dial out”) require cua and 
cul device files. 


The following entries require that umask 111 be executed before using mknod. The general 
template for ports is shown in Table 5-5. 

Table 5-5. Port Information for mknod 


Device 

c/b 

Major 

Minor 

Notes 

tty XX 

c 

M 

OxScAdO V 

Sc^ Ad and V are explained below 

ttydxx 

B 

M 

OxScAdOV 

Sc, Ad and V are explained below 

cuaxx 


M 

QxScAdO V 

Sc, Ad and V are explained below 

culxx 

C 

M 

OxScAdD V 

Sc, Ad and V are explained below 


XX a two-digit line identifier 

M the major number (29 for the HP 27140, and 31 for the HP 27128 or HP 27130) 
Ox shows that the following number is hexadecimal 

Sc the select code of the interface being used (the slot number the interface card is 
in) 

Ad the port address for each port, beginning with number 0. 

If you are using a single port interface such as the HP 27128A ASI card, the port 
address will be 00 (so the minor number would be OxScOOOO in our first example 
above). 

For multi-port interfaces such as the HP27130B eight-channel MUX card or the 
HP 27140A six-channel modem MUX card, the port address is the RS-232 port 
number your terminal is plugged into. With, for example, tty09 plugged into the 
second port of an HP27130B interface at select code 6, the correct mknod would 
look like: 

/etc/mknod tty09 c 31 0x060100 
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OV The digit before the volume number (v) is always 0. The volume number in the 
device file minor field, has special meaning with ASI and MUX cards. V should 
always be a zero (0) for the HP 27130 8-channel MUX. To properly configure your 
system to talk to modems and data links via ASI and 6-port modem MUX cards, 
refer to Tables 5-6 and 5-7. 

Table 5-6. ASI Volume Numbers 


Bit Order 

When Clear (0) 

When Set (1) 

3 

Ignored 

Ignored 

2 

Ignored 

Ignored 

1 

Simple Protocol 

CCITT Protocol 


(United States) 

(Europe) 

0 

Dial-in 

(Direct Connect) 

Dial-out 


Table 5-7. MUX Volume Numbers 


Bit Order 

When Clear (0) 

When Set (1) 

3 

Ignored 

Ignored 

2 

Ignored 

Direct Connect (overrides 
bit 0) 

1 

Simple Protocol 

CCITT Protocol 


(United States) 

(Europe) 

0 

Dial-in 

Dial-out 


HP-UX associates the system console port with the device file /dev/console. This may 
or may not be an ITE (Internal Terminal Emulator). 

Example Port Device Files 

Assume that you want to create device files for a modem at select code 2 (using an 
HP27128A ASI card), and associate it with /dev/tty04. Because the modem will be 
used as a dial-in and dial-out port, log in as the root user and use the following mknod 
command lines: 


cd /dev 
/etc/mknod 

ttyd04 

c 

31 

0x020000 

/etc/mknod 

cua04 

c 

31 

0x020001 

/etc/mknod 

cul04 

c 

31 

0x020001 
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Notice that the minor number for the cua and cul device files ends with a 1. There are 
now three device files associated with the dial-in and dial-out modem at select code 2. 


Note 

A single-user HP-UX Series 500 system can have a maximum of 2 
ports: a system console and 1 additional port which is used with 
uucp. 

A multi-user HP-UX Series 500 system can have a maximum of 16, 
32 or 64 ports—depending upon which license you have purchased. 
(This is the maximum number of ports that may be used by lo¬ 
gin). For some systems (and for certain applications), using this 
maximum number of ports may be counter-productive in terms of 
performance, disk space and available memory. 


For setting up ports for UUCP, refer to the UUCP article in Concepts and Tutorials for 
a more detailed explanation. 

Terminal Configuration Information 

A complete list of the terminals supported by Series 500 HP-UX is provided in the HP 
9000 Series 500 Configuration Information and Order Guide supplied with your system. 
The Installation Guide supplied with your computer discusses the hardware aspects of 
hooking up a terminal to your system. This section offers the software configuration 
information you need. 

After dealing with the hardware hookups, terminals must be configured so they can 
“talk” to HP-UX. Series 500 HP-UX requires that terminals be configured to have the 
characteristics listed below. If a particular configuration option is not available on your 
HP terminal, then the option is already properly chosen (as a default value) by the 
terminal. 
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Terminal Parameters 

The manual supplied with the terminal describes how to use the function keys to config¬ 
ure the terminal. Generally, you will press a key that chooses the “terminal configura¬ 
tion” option and alter the appropriate fields by answering prompts from the terminal’s 
configuration program. Configure the terminal with the following values: 


Tab=Spaces 

NO 

RETURN Def 

CR 

RETURN=ENTER 

NO 

LocalEcho 

OFF 

CapsLock 

OFF 

Start Col 

1 

ASCII 8 Bits 

YES 

XmitFnctn(A) 

NO 

SPOW(B) 

NO 

InhEolWrp(C) 

NO 

InhHndShk(G) 

YES 

Inh DC2(H) 

YES 


Datacomm Parameters 

For datacomm purposes, the following configuration parameters should also be set. The 
method for setting these values is similar to that outlined above; details are provided in 
the manual supplied with the terminal. 

These configuration parameters must be set the same on your terminal/console as on your 
system. On the system the parameters can be set temporarily using the stty command. 
They can also be set for your datacomm line using the /etc/gettydefs file. When you 
log in, your terminal is associated with a line in /etc/inittab. The getty command 
in /etc/inittab initializes your line with the options in the associated /etc/gettydefs 
file. You must set your terminal to match those characteristics specified in the getty for 
the device. Refer to the inittab(4), gettydefs(4), and getty(lM) entries in the HP-UX 
Reference. 

The following datacomm parameters are recommended for HP-UX. Notice that DataBits 
and EnqAck are different from what you originally set up for the system console. 
DataBits should be set to 8 if you are using 8-bit characters (such as for NLS). En¬ 
qAck should be “no” so you can utilize the "F (scroll by 1 page) in vi. 


Parity 

NONE 

DataBits 

8 

Clk 

INT 

StopBits 

1 

EnqAck 

NO 

TR(CD) 

HI 

Chk Parity 

NO 

RecvPace 

Xon/Xoff 

SRRXmit 

NO 

RR(CF)Recv 

NO 

XmitPace 

Xon/Xoff 

SRRInvert 

NO 

CS(CB)Xinit 

NO 
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Except in the case of using the terminal as a system console (discussed below), you may 
use any baud rate that the terminal will handle. The baud rate setting on the terminal 
must match the baud rate parameter in the getty command located in the terminal’s 
entry in the /etc/inittab file as discussed below. 

If you are using the terminal as the system console, set the terminal’s baud rate at 9600 
to match the HP-UX expectation for the system console. After the system is installed 
and running, you may change some of the configuration parameters to suit your own 
needs. For example, changing the HP-UX expectation for a particular baud rate is done 
by modifying one of the parameters to the getty command located in the /etc/inittab 
file (and associated with the terminal in question). Further information is provided 
in the section that follows (“Special Considerations for Terminals”), in the getty(IM)^ 
gettydef(4), and inittab(4) entries in the HP-UX Reference, and in the “System Startup 
and Shutdown” chapter of this manual. 

Special Considerations for Terminals 

When a terminal is added to the system, you must perform the steps described in the 
preceding section and add entries to the /etc/ttytype and /etc/inittab files. This allows 
a user to log in from the terminal. Add entries to these files as described below. 

The /etc/ttytype entries have the form: 
model_number location 

where modeLnumber is the the product number of the terminal or computer (as defined 
in /etc/terminfo) and location is the device file associated with the terminal/computer 
and contained in the /dev directory. Placing comments on each line (preceded by the # 
character) will help you remember which terminal belongs to each user. 

Here is a sample /etc/ttytype: 


9020 

console 

# 

Frodo*s (administrator) system console 

2622 

ttyOO 

# 

Bilbo’s terminal 

2622 

ttyOl 

# 

Gandalf’s terminal 

2623 

tty02 

# 

Strider’s terminal 

dialup 

tty03 

# 

Greybeard’s dialup modem 


Most /etc/inittab entries have the form: 

id:rstate:action:/etc/^etty -txxx device_fHe_name N X 
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The first three fields (shown as id, rstate, and action) are discussed both in init(lM) 
in the HP-UX Reference manual and in this manual’s “System Startup and Shutdown” 
chapter. The normal values for these fields are: id = unique two character string, rstate 
= 2, and action = respawn (for continuous). 

The two-character string id is arbitrary but must be unique for each entry. It is used 
to refer to the same entry/process in other states. The respawn flag specifies that the 
command in the command field (such as getty) is to be re-invoked once the process 
terminates (typically, when a user logs off the system). 

The fourth field must contain the /etc/getty command; it is immediately followed by 
three parameters. The first parameter, -t xxx, is the optional time-out option for use 
with modems. The second parameter, device_fHe_name is the file name (tty04) — not 
the complete path name (/dev/tty04) — of the terminal’s or modem’s character device 
file. The named file must reside in the /dev directory. The third parameter to getty, 
represented by N, specifies a speed indicator for getty; a value of H is common for 
“hardwired” (9600 baud terminal) lines, a value of 3 is common for dial-up (300/1200 
baud modem) lines. For more information, see the getty(lM) and gettydef(4) entries in 
the HP-UX Reference manual. 

For example, to add a terminal on /dev/tty04 the /etc/inittab entry would be: 

04:2:respawn:/etc/getty tty04 H 

Note that the id field 04 corresponds to the last two digits of the device file (tty04) for 
the terminal on which getty is invoked. This convention is often used with “continuous” 
getty processes that get killed in the single-user state but is not required syntax: any 
two-character string will suffice if used consistently. 

The system will recognize the new getty only if /etc/inittab is re-read. You can cause 
the system to re-read inittab either by changing states or by executing /etc/telinit 
{init(lM)). On a multi-user system, be certain to set up /etc/inittab terminal entries 
for each terminal connected to the system. Refer to the “System Startup and Shutdown” 
chapter in this manual and to the getty(lM), gettydef(4), and inittab(4) entries in the 
HP-UX Reference for further details. 
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Dealing with an Unresponsive Terminal 

If, for whatever reason, a terminal will not respond (or does not appear to respond) to 
your commands, two solutions are available. The first is to simply log off the system 
(using exit or | CTRL | b~| ) and then login again. Generally this will clear up any problems. 

Another solution is to type the following exactly as shown — blanks are significant. You 
may not see anything echoed on the screen. If you have a hardwired terminal on an 
HP 27128 ASI card, this action may log you off of HP-UX. 

I CTRL H J I stty sane erase ""H" kill "^U" echo ] CTRL~| - | J | 

This sets the “erase” character to | CTRL H H | and the “kill” character to | CTRL H U I - 
When the screen and keyboard response returns, type: 

tset 

Your terminal should now exhibit proper behavior. As another option to this procedure, 
you may also do a hard reset of your terminal, and then execute the tabs command. 

Consoles 

To successfully boot and use HP-UX, you must have a supported terminal device as the 
system console. This list includes (but is not limited to) the built in ITE of a Model 520, 
the HP 98700 display system on a Model 550, and the HP 2623. The console always has 
the device file /dev/console. HP-UX will also link two additional files to /dev/console— 
they are /dev/syscon and /dev/systty. For more information on the selection of the 
console and how HP-UX selects the console, see Chapter 4 (“System Startup and Shut¬ 
down”) of this manual. 

There are four basic configurations possible to “talk” to your console; they are: 

• the built-in terminal (ITE) of the Model 520, which always has a major number of 
29, and a minor number of 0x000000. 

• any ASI or 8-channel modem MUX card; the major number will be 31, and the 
minor number must be 0x000000. If the boot ROM does not find a supported 
console at select code 0, port 0, unit 0 and volume 0, or an HP 98700, then HP-UX 
will fail. 

• a 6-port modem MUX, which has a major number of 29, and a minor number of 
0x000004. 
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• an HP 98700 display device on a Model 550. Up to three HP 98288A Display Station 
Buffer (DSB) cards may be placed on the stack (by your Customer Engineer), from 
slots 4 thru 7. The lowest ordered DSB will become your system console, and would 
have a major number of 29 and a minor number of Oxff AdOO where f f indicates the 
device is located in the stack, and Ad is the slot. Slot 4 would become OxffOOOO, 
while slot 7 would become Oxf f0300. 

• if you have both a terminal at 0x000000 and an HP 98700 display device, the display 
device will be selected as the console. 

Make sure the appropriate driver is installed in your boot area before attempting to 
reboot your system configured to talk to a different console. 

Pseudo Terminals 

Often applications need some form of software support which enables an application 
program to pretend it has a terminal. This is accomplished by using a pseudo terminal. 
A pseudo terminal is a pair of character devices: a master device and a slave device. The 
slave device provides processes (in this case, user applications) an interface identical to 
that described in termio(7) of the HP-UX Reference manual. 

The difference between an HP-UX pseudo terminal and the interface described in termio, 
is that the latter always have a hardware device of some sort behind them—like an 
HP 2623 terminal. A slave device, on the other hand, has another process manipulating 
it through the master half of the pseudo terminal. Anything written on the master device 
is given to the slave device as input, and anything written on the slave device is presented 
as input on the master device. 

Table 5-8. PTY Information for mknod 


Device 

c/b 

Major 

Minor 

Notes 

ptyXX 

c 

45 

OxfeYYOO 

Master side of pseudo terminal 

ttyXX 

c 

29 

OxfeYYOO 

Slave side of pseudo terminal 


According to HP-UX naming conventions, the master side device file should be called 
/dev/ptym/ptyXX, and the slave side /dev/pty/ttyXX, where XX is an identifying let¬ 
ter from p to w, and a hexadecimal digit. As an example, /dev/ptym/ptypO (mas¬ 
ter) and /dev/pty/ttypO (slave) would be the lowest numbered pseudo terminal pair; 
/dev/ptym/ptywf and /dev/pty/ttywf would be the highest ordered pair. 
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YY is a unique hexadecimal value used to identify the relationship between master and 
slave (a lot like a cattle brand). 

As an example: 

/etc/mknod /dev/ptym/ptypO c 45 0xfe7700 
/etc/mknod /dev/pty/ttypO c 29 0xfe7700 

would create a master and slave pair called ptypO and ttypO. 

Note that all pseudo terminal devices are located in the directories /dev/pty (slaves), and 
/dev/ptym (masters)—do not change these naming conventions. For more information on 
pseudo terminals, see both the termio(7) and pty(7) sections of the HP-UX Reference 
manual. 

Hard Disks, Flexible Disks, and Cartridge Tapes 

When you set up your mass storage media, you must create device files for them. The 
four items that must go into the mknod command line are: 

• Name of the file. 

Using HP-UX naming conventions, the device file names will be created under 
special directories in the /dev directory. A character device is distinguished from a 
block device by placing all character devices in a directory that starts with V’. For 
example, the device file names for an HP 7945A disk drive that will be a mounted 
file system might be: 

/dev/dsk/lsO (block) 

/dev/rdsk/lsO (character) 

The directories, and a description of their use, follows: 

• /dev/dsk — Block device files for hard disks and flexible disks. 

• /dev/rdsk — Character device files for hard disks and flexible disks. 

• /dev/ct — Block device files for cartridge tape. 

• /dev/rct — Character device files for cartridge tape. 
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These naming conventions are different than previous releases of HP-UX. Your 5.2 
HP-UX system was installed using the old naming convention, but we recommend 
switching to the new naming convention. To convert existing files to the new 
naming convention use the procedures in the section “New Device File Naming 
Conventions”. Both this convention and the old convention is supported for this 
release (5.2). You should use the new naming convention since the old one may not 
be supported in future releases. 

• type of the device file 

Each hard disk (except the root disk), flexible disk, and cartridge tape drive must 
have two device files associated with it: a block device file and a character device 
file. 

• major number 

The major number differs between different types of mass storage devices. For most 
mass storage devices the major number will be 1. Look up the product number of 
your mass storage device in Table 5-10 at the end of this section. 

• minor number 

The address-dependent minor number is the same for both block and character 
entries. 

The minor number consists of a select code (the slot number the interface card is 
installed in), HP-IB address (set on the mass storage device), unit number, and 
volume number (usually 0). For each possible HP-IB address where mass storage 
devices may be located, there can be several minor numbers. 

You must have restricted access permission on all device files that are associated with 
mountable file systems, giving read/write permission to the owner (root) only. This 
prevents someone from mounting unauthorized media on your system, and prevents 
everyone on the system from accidentally overwriting a file system residing on the device 
associated with this device file. 

If you have set up a new hard disk, you should type (to change both block and character 
files): 

chmod 600 /dev/rdsk/device_file_name 
chmod 600 /de^/ds^/device_fHe_name 
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CS/80 and SS/80 “root” Disk and Cartridge Tape 

Table 5-9 shows the default device files created during the installation process. These 
represent your root file system device and the device file associated with the cartridge 
tape you installed from. Two device file names are given: when first installed, your root 
device will have the old naming convention (/dev/hd and /dev/rhd), if you have run the 
mvdevs script your rood device will have the new naming convention (/dev/dsk/OsO and 
/dev/rdsk/OsO). Note that the minor number is based on the hardware address. 

Table 5-9. Root Disk and Cartridge Tape Default Device Files 


Device after 
Installation 

Device after 
Mvdevs 

c/b 

Major 

Minor 

/dev/hd 

/dev/dsk/OsO 

b 

1 

OxScAdUV 

/dev/rhd 

/dev/rdsk/OsO 

c 

1 

OxScAdUV 

/dev/update.src 

/dev/update.src 

c 

1 

OxScAdUV 
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A complete listing of supported CS/80 and SS/80 devices is shown in Table 5-10. As you 
add peripherals to your system, such as a second HP 7914P disk drive, you will want to 
look up the major and minor number configurations for that device. 


Table 5-10. Supported Mass Storage Devices 


Product 

Number 

Description 

Major 

Minor 

HP 7908P/R 

16.5 Mbyte CS/80 Disk Drive 

1 

OxScAdOO 

HP7911P/R 

28.1 Mbyte CS/80 Disk Drive 

1 

OxScAdOO 

HP7912P/R 

65.6 Mbyte CS/80 Disk Drive 

1 

OxScAdOO 

HP 7914P/R 

132.1 Mbyte CS/80 Disk Drive 

1 

OxScAdOO 

HP 7914TD 

132.1 Mbyte CS/80 Disk Drive 

1 

OxScAdOO 

HP 7933H 

404 Mbyte CS/80 Disk Drive 

1 

OxScAdOO 

HP 7935H 

404 Mbyte CS/80 Disk Drive 

1 

OxScAdOO 

HP 7941A 

23.8 Mbyte CS/80 Disk Drive 

1 

OxScAdOO 

HP 7945A 

55.5 Mbyte CS/80 Disk Drive 

1 

OxScAdOO 

HP 7946A 

55.5 Mbyte CS/80 Disk Drive and Cartridge 
Tape Drive 

1 

OxScAdOO 

HP 97093A 

Model 520 builtin 10 Mbyte CS/80 Disk Drive 

1 

0x070000 

HP9122S/D 

Single (or dual) 630 Kbyte Micro Disk 

1 

OxScAdUO 

HP9125S 

Single 270 Kbyte 5V4 inch Floppy 

1 

OxScAdOO 

HP9130K 

Model 520’s built-in 256 Kbyte CS/80 Flexible 
Disk Drive 

1 

0x070010 

HP9133H 

22.3 Mbyte CS/80 Disk, 630 Kbyte Micro Disk 

1 

OxScAdOO 

HP 9134H 

22.3 Mbyte CS/80 Disk 

1 

OxScAdOO 

HP9144A 

Stand alone CS/80 cartridge tape 

1 

OxScAdOO 

HP 82901M 

540 Kbyte capacity, 5V4 inch Flexible Disk Drive 
(dual drive, master) 

8 

OxScAdUO 

HP 82902M 

270 Kbyte capacity, 5V4 inch Flexible Disk Drive 
(single drive, master) 

8 

OxScAdUO 

HP 9895A 

2.4 Mbyte capacity, 8 inch Flexible Disk Drive 
(dual, master) 

6 

OxScAdUO 
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Table 5-10. Supported Mass Storage Devices (cont.) 


Product 

Number 

Description 

Major 

Minor 

HP 9885M 

0.5 Mbyte capacity, 8 inch Flexible Disk Drive 
(single, master) 

9 

OxScOOUO 

HP 9885S 

0.5 Mbyte capacity, 8 inch Flexible Disk Drive 
(single, slave) 

9 

OxScOOUO 

HP 88140L 

67 Mbyte built-in CS/80 cartridge tape drive of 
the following disk drives: 

• HP7911P/R 

• HP 7912P/R 

• HP 7914P/R 

1 

OxScAdlO'* 

HP88140S 

16.7 Mbyte built-in CS/80 cartridge tape drive 
of the HP 7908P/R disk drive 

1 

OxScAdlO^ 


Nine-Track Magnetic Tape 

When you set up your magnetic tape driver, you must create device files for them. The 
four items that must go into the mknod command line are: 

• name of the file 

Using HP-UX naming conventions, you should create the device file under special 
directories in the /dev directory. A character device is distinguished from a block 
device by placing all character devices in a directory that starts with ‘‘r”. /dev/mt 
will hold block device files for magnetic tape (this is not currently supported, but 
is reserved), /dev/rmt will hold character device files for magnetic tape. 

Refer to the section “Naming Conventions for Magnetic Tape”. 

These naming conventions are different than previous releases of HP-UX. Your 5.2 
HP-UX system was installed using the old naming convention. To convert magnetic 
tape device files using the old naming convention to the new naming convention, use 
the procedures in ''New Device File Naming Conventions”. Both this convention 
and the old convention are supported for this release (5.2). You should begin 
using the new naming convention since the old one may not be supported in future 
releases. 


4 


The minor number shown is for a single controller drive. For a dual controller drive, use OxScAdOO. 
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• type of the device file 

All magnetic tape drive device files should be character type. 

• major number 

The major numbers for magnetic tape drives is shown in Table 5-11. 

• minor number 

The minor numbers for magnetic tape drives is described below. 


Table 5-11. Nine-Track Tape Devices 


Product 

Number 

Description 

Major 

Minor 

HP 7970E 

9 -track Tape Drive (1600 bpi) 

11 

OxScAdOV 

HP 7971A 

9-track Tape Drive (1600 bpi) 

11 

OxScAdOV 

HP 7974A 

9 -track Tape Drive (800 or 1600 bpi) 

36 

OxScAdUV 

HP 7978A 

9-track Tape Drive (1600 or 6250 bpi) 

36 

OxScAdUV 


Magnetic Tape Minor Number 

The minor number consists of the following fields: 

OxScBaUV 

Ox This prefix indicates the number is hexadecimal. 

Sc This field is the hexadecimal representation of the select code. The select code is 
the slot number the interface card is in. 

Ba This field is the HP-IB bus address. It is determined from the switch settings on 
the tape drive. 

U The single hexadecimal unit number (U) represents a four-bit binary value. Set¬ 
ting and clearing the bits of this binary value affects the manner in which the tape 
drive operates, as indicated in Table 5-12. 
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Table 5-12. Unit Number for Magnetic Tape 


Bit Order 

When Clear (0) 

When Set (1) 

7 

Industry Standard mode 

Old compatibility mode 

6 

Immediate report on (ig¬ 
nored by HP 7970/7971) 

Immediate report off (ig¬ 
nored by HP 7970/7971) 

5 

Reserved (ignored) 

Reserved (ignored) 

4 

Tape density of 1600 bpi 
(ignored by HP 7970/7971) 

Tape density of 800 bpi 
on HP 7974; 6250 bpi 

on HP 7978 (ignored by 
HP 7970/7971) 


V The volume number (V). The single hexadecimal volume number (V) represents 
a four-bit binary value. Setting and clearing the bits of this binary value affects 
the manner in which the tape drive operates, as indicated in Table 5-12. 


Table 5-13. Volume Number for Magnetic Tape 


Bit Order 

When Clear (0) 

When Set (1) 

3 

Ignored 

Ignored 

2 

Rewind on close 

No rewind on close 

1 

System V file compatibility 

Berkeley file compatibility 


mode 

mode 

0 

Ignored 

Ignored 


For more information on the use of magnetic tape, see Chapter 3 (Concepts) of this 
manual, or the mt(7) section of the HP-UX Reference manual. 

Naming Conventions for Magnetic Tape 

The naming convention described in mt(7) of the HP-UX Reference is useful for keeping 
track of how a tape drive minor number is set up. The device /dev/rmt/Omn is the 
first tape mechanism, medium (1600) density, no rewind. The device /dev/rmt/Oh is the 
same mechanism configured for high (6250) density operation, rewind on close (note the 
absence of n suffix). 
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If you connected an HP 7978 tape drive to select code 5, set the tape drive’s bus address 
to 3, and executed the following commands: 

mknod /dev/rmt/Omn c 36 0x050304 
mknod /dev/rmt/Oh c 36 0x050310 

you could access the same drive as a 6250 bpi device using the “Oh” device and as a 1600 
bpi device using the “Omn” name. You could also use the “mt” command to do various 
positioning operations on the tape without having to provide a device name because mt 
uses the default device /dev/rmt/Omn. Since tar defaults to /dev/rmt/Om you may also 
wish to create this file. 

Printers 

This section provides the mknod information needed to create device files for the printer 
device class. You can use this information, or you can use the /etc/mklp script to create 
device files for printers. See the “Setting Up the LP Spooler” section later in this chapter 
for information on /etc/mklp. 


Note 

For all HP-supported printers, you can use the mknod command 
lines in the /etc/mklp script as guideline for creating the printer 
device file. This script is described in more detail in the section, 
“Setting Up the LP Spooler” later in this chapter. 


To create device files for a printer, first determine the printer’s location (i.e., interface 
and bus address). Use the guidelines given earlier in this section and in the Installation 
Guide supplied with your computer to select the most appropriate location. Finally, 
create the device file for the printer using either the mknod command or the /etc/mklp 
script. You must assign a unique device file name to each entry you create; see the 
intro(7) entry in the HP-UX Reference for a suggested naming convention. If you are 
not using the /etc/mklp script, you must execute umask 111 before using mknod. 

All printers on HP-UX are character devices, but they can be used in different “modes”: 
you can communicate with printers using drivers that either interpret (cooked mode) or 
do not interpret (raw mode) the data. The /dev/mklp script has templates for the correct 
mknod command lines. 
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Table 5-14. Supported Printing Devices 


Product 

Number 

Description 

Suggested 

Pathname 

Major 

Minor 

HP 2225A 

150 cps Think Jet printer 

/dev/lp2225a 

12,22,37® 

OxScAdUV'^ 

HP 2563A 

300 lines per minute dot-matrix im¬ 
pact printer 

/dev/lp2563a 

12,22,14® 

OxScAdUV'^ 

HP 2565A 

600 lines per minute dot-matrix im¬ 
pact printer 

/dev/lp2565a 

12,22,14® 

OxScAdUV^ 

HP 2566A 

900 lines per minute dot-matrix im¬ 
pact printer 

/ dev/lp2566a 

12,22,14® 

OxScAdUV^ 

HP 2601A 

40 characters per second Daisywheel 
Impact Printer 

/dev/lp2601a 

22 

OxScAdOO 

HP 2602A 

25 characters per second Daisywheel 
Impact Printer 

/dev/lp2602a 

22 

OxScAdUV 

HP 2608S 

400 lines per minute dot-matrix im¬ 
pact printer 

/dev/lp2608s 

14 

OxScAdUV'^ 

HP 263IB 

180 cps dot-matrix impact printer 

/dev/lp2631b 

22 

OxScAdUV'^ 

HP 263IG 

180 cps dot-matrix impact printer 

/dev/lp2631g 

12,22,37® 

OxScAdUV'^ 

HP 2671A 

120 cps dot-matrix thermal printer 

/dev/lp2671a 

22 

OxScAdUV^ 

HP 267IG 

120 cps dot-matrix thermal printer 

/dev/lp2671g 

12,22,37® 

OxScAdUV^ 

HP 2673A 

Intelligent dot-matrix graphics ther¬ 
mal printer 

/dev/lp2673a 

12,22,37® 

OxScAdUV'^ 

HP 2932A 

200 cps dot-matrix impact printer 

/dev/lp2932a 

12,22,37® 

OxScAdUV'^ 

HP 2933A 

200 cps dot-matrix impact printer 

/dev/lp2933a 

12,22,37® 

OxScAdUV^ 

HP 2934A 

200 cps dot-matrix impact printer 

/dev/lp2934a 

12,22,37® 

OxScAdUV’^ 
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Table 5-14. Supported Printing Devices (Cont.) 


Product 

Number 

Description 

Suggested 

Pathname 

Major 

Minor 

HP 82906A 

160 cps dot-matrix impact printer 

/dev/lp82906a 

12,22,37® 

OxScAdUV^ 

HP97090A 

Model 520 built-in thermal printer 

/dev/lp97090a 

22,26* 

0x060000 

HP 2680A 

45 page per minute laser printer 

/dev/lp2680a 

35 

OxScAdOO 

HP 2686A 

8 page per minute laser printer 

/dev/lp2686a 

22/31*® 

OxScAdOO 

HP 2688A 

12 page per minute laser printer 

/dev/lp2688a 

35 

OxScAdOO 


Unit and Volume Numbers for Printer Device Files 

The unit and volume number fields of the minor number have special meaning when 
creating device files for printers. 

For the HP-UX printer driver (major number 22), the single-digit hexadecimal value for 
Volume is made up of four bits, two of which control the wrap-around and character-per- 
line characteristics of the printer. The Unit number is 0. Table 5-15 shows and describes 
the bits involved when connected over HP-IB with non-CIPER protocol: 


Table 5-15. Volume Number for non-CIPER Printer Protocol 


Bit Order 

When Clear (0) 

When Set (1) 

3 

Ignored 

Ignored 

2 

Ignored 

Ignored 

1 

Disable wrap-around 

Enable wrap-around 

0 

132 character line length 

80 character line length 


For example, a printer at select code 3 and bus address 3 would use the following mknod 
command for wrapping around after 80 characters: 

mknod /dev/lpxxxxa c 22 0x030303 

For major number 14 (CIPER printer driver), the unit number flags whether the device 
file handles the data in “cooked” mode or “raw” mode. Volume number is always 0. 


® When connected via HP-IB, use driver 12 for raw mode and driver 22 for cooked mode. When connected 
via the Model 550’s internal HP-IB, use driver number 37 for raw mode and driver 22 for cooked mode. 

^ See the “Unit and Volume Numbers for Printer Device Files” section which follows. 

® Use driver 26 for raw mode and driver 22 for cooked mode. 

^ For option 200, use driver 12 for raw mode and driver 22 for cooked mode. For option 290, use driver 
14 for both raw and cooked mode. 

For raw output use driver 31, for cooked output use driver 22. 
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Table 5-16. Unit Number for CIPER Printer Protocol 


Bit Order 

When Clear (0) 

When Set (1) 

3 

Ignored 

Ignored 

2 

Ignored 

Ignored 

1 

Ignored 

Ignored 

0 

raw mode 

cooked mode 


Using Printers as Spooled Devices 

There is one additional decision you need to make. Printers can be accessed through 
the line printer spooler (refer to the lp(l) entry in the HP-UX Reference) as spooled 
devices; files are kept in a spool directory until the device is ready to process them. If 
your printer is set up as spooled device, you can direct output to it at any time, whether 
it is busy or not. 

Follow the guidelines in the “Setting Up the LP Spooler” section of this chapter to 
create the printer device file and set up the spooler system. That section also explains 
commands which control the LP (line printer) Spooler. 

RS232 Printers 

If you have an RS232 printer that is not associated with a model (refer to the section 
“Setting Up the LP Spooler” section), then you must modify your /etc/rc file. The 
commands you add to your /etc/rc file depend on the printer and must include things 
like the transmission baud speed, parity, and ENQ/ACK or XON/XOFF pacing; they 
configure the datacomm line so information can be sent to the printer. 

For example, if you have an HP 2686A LaserJet Printer associated with the device file 
/dev/lp, you should add the following lines to /etc/rc: 

nohup sleep 2000000000 < /dev/lp & 

stty -parenb -ienqak cs8 9600 -cstopb -clocal ixon opost onlcr tab3 < /dev/lp 

nohup tells the system not to send a hang-up signal even when the process terminates. 
The sleep command receives input from the device associated with /dev/lp. Once the 
line is open, the stty command is used to configure the line. 

The options required for your printer should be documented in the “interface” or “con¬ 
figuration” section of the printer’s manual. The options for stty are documented in 
termio(l). 
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Plotters and Digitizers 

This section provides the mknod information needed to create device files for the plotter 
and digitizer device classes. 

To create a device file for a device in this class, first determine the peripheral’s location 
(i.e., interface and bus address). Use the guidelines given earlier in this section and in 
the Installation Guide supplied with your computer to choose an appropriate location. 
Then use Table 5-17 to find the major number that corresponds to that specific device. 
Finally, create the device file for the printer using the mknod command. Remember to 
execute umask 111 before using mknod. 


Table 5-17. Supported Graphic Devices 


Product 

Number 

Description 

Suggested 

Pathname 

Major 

Minor 

HP 7470A 

A-size, single pen plotter 

/dev/plt7470a 

12 

OxScAdOO 

HP 7475A 

B-size, 6 pen plotter 

/dev/plt7475a 

12 

OxScAdOO 

HP 7550A 

B-size, 8 pen plotter 

/dev/plt7550a 

12 

OxScAdOO 

HP 7580B 

D-size, 8 pen plotter 

/dev/plt7580b 

12 

OxScAdOO 

HP 7585B 

E-size, 8 pen plotter 

/dev/plt7585b 

12 

OxScAdOO 

HP 7586B 

E-size, 8 pen, roll feed plotter 

/dev/pit7586b 

12 

OxScAdOO 

HP 9872C 

B-size, 8 pen plotter 

/dev/plt9872c 

12 

OxScAdOO 

HP 9872T 

B-size, 8 pen plotter 

/dev/plt9872t 

12 

OxScAdOO 

HP 98700 

Graphics display system 

/dev/plt98700 

15 

OxffAdOO 

HP 98710 

Graphics accelerator 

/dev/plt98710 

15 

OxAdOOOO 

HP98760A 

Standard color display on the Model 
520 

/dev/plt98760a 

32 

0 x010000 

HP98770B 

High performance display on the 
Model 520 

/dev/plt98770b 

28 

0 x010000 

HP 98780B 

Monochromatic display on the Model 
520 

/dev/plt98780b 

28 

0 x010000 

HP 97062A 

Color output interface on the Model 
520 

/dev/plt97062a 

32 

OxScOOOO 

HP9111A 

Data Tablet 

/dev/dig9111g 

12 

OxScAdOO 
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Useful Naming Conventions 

You must assign a unique device file name to each entry you create. The intro(1) entry 
in the HP-UX Reference explains device file naming conventions. Generally, use rip 
followed by the product number for raw printers, pit followed by the product number 
for plotters, and dig followed by the product number for digitizers. If more than one 
device with the same product number is present, be certain not to duplicate their device 
file names. For example, to differentiate between two HP 9872 plotters, name the first 
one plt9872 and the second plt9872.1. 
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Adding/Removing Users 

The rnaierial in this section covers only the software or configuration aspects of 
adding/removing a user to/from the HP-UX system. If the user will have his own ter¬ 
minal, you need to install the terminal and do some associated configuration before the 
user can log in to the system; see the “Adding/Moving Peripheral Devices” section of 
this chapter. 

Each user is defined by an entry in /etc/passwd. Without this entry, the user cannot 
log in. To add a user to the system, you must add a line to this file and do a few other 
things. A complete description of the /etc/passwd file can be found in the passwd(4) 
entry in the HP-UX Reference manual. 

Two approaches for adding users to the system are offered here. Both approaches require 
the aforementioned entry in the /etc/passwd file. The procedure for creating that entry 
is explained next. Following that, a listing of a shell script that partially automates 
the process of adding users to the system is supplied. Finally, a step-by-step method for 
adding users is presented. If you expect to add a few users to the system, it will probably 
be worth your time to type in the shell script listed below to ease the task of adding users. 
If you have a single-user system or expect to add only one or two users to your system, 
the step-by-step process will probably be your best choice. Both approaches accomplish 
the same task; the “automation” of adding users is the only functional difference between 
the two. 

Creating the /etc/passwd Entry 

To create an entry in the /etc/passwd file for the new user, first log in to the system as 
the super-user root. 

If this is the first time you are following this procedure, make a copy of the original 
/etc/passwd that was shipped with your system before continuing. To copy the file, 
type: 

cp /etc/passwd /etc/passwd.old 

where /etc/passwd.old will be your unmodified (original) copy of the file. 
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Next, using the text editor of your choice (such as ed, vi, or ex), edit the file /etc/passwd. 
Add a line to the file describing the new user. The new line must have the form (the 
description follows): 

user_name :: user^id:group_id:comment:login_directory:command 

The colon character (:) is used to delimit the various fields in the entry. 

user_^name is the user’s login name, consisting of 1 to 8 lowercase letters or other char¬ 
acters. 

: : represents an empty password field. Passwords and the passwd command are discussed 
later in this section. 

us€r_id is the real user ID — a unique integer value that the system uses to identify the 
user. If the real user ID is 0, then that user has super-user capabilities. As the system 
was shipped to you, the real user ID 0 is associated with the user root. By convention, 
the values 1 through 99 are reserved for system use. Therefore, pick any unused number 
greater than 99 for this field. 


NOTE 

There should be only one entry per real user ID; the user whose 
real user ID is 0 should be named root. 


group^id is the real group ID — an integer value shared by all members of the same 
group. This entry corresponds with the group entry in /etc/group; see the “Creating 
Groups/Changing Group Membership” section in this chapter for details. 

comment is a word or phrase that identifies the user or specifies the reason for the 
entry. Typically, this field contains the user’s full name and other information such as 
his location or phone number. 

login^directory is the absolute path name of the user’s login directory. This becomes the 
user’s working directory when he logs in. The directory need not exist when the entry 
to /etc/passwd is made. However, the directory must exist before the user can log in. A 
user’s login directory is usually a subdirectory of the /users directory and has the same 
name as the user’s login name. For example, a user whose last name is Young might 
have login name young and home directory /users/young. 
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command is the name of a single command to be executed for the user at login —^ this 
should be an absolute pathname. Typically, /bin/sh (or /bin/csh) is placed in this field to 
invoke the shell (or C-shell) for the user. However, the name of any executable program 
or command may be placed in this field. The command can be either a compiled program 
or a shell script but no arguments to the command or script should be supplied. If the 
command field is left blank, /bin/sh is executed by default. When the user logs in, the 
command listed in this field is executed and control is passed to that program. Once the 
program terminates, the user is logged out. 

Once you are satisfied with the contents of /etc/passwd, write the modified file to the 
disk and terminate the editing session. 

The ''Makeuser” Script 

This section contains the shell script for adding users to the system. This script assumes 
that certain files are located where they were when the system was shipped. If you have 
moved these files, edit the script to match their new locations. 

To use this script, you need to: 

• Log in to the system as the super-user root. 

• Use one of the text editors to create the /etc/makeuser file by typing in the listing 
below. The name /etc/makeuser is only a suggestion. 

• Change the mode of the file by typing: 

chmod 744 /etc/makeuser | Return | 

This gives you read, write and execute permission on the file but restricts the access 
of all other users to read permission. 

• After creating the new user’s /etc/passwd entry, execute the script by typing: 

/etc/makeuser user_name \ Return | 

where user^name is the new user’s username from the /etc/passwd entry. 
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Here is the “makeuser” shell script: 

: #/etc/makeuser: create a new user 

USERS=/users 
if [ $# != 1 ] 
then 

echo "Usage: makeuser name" 
exit 1 
f i 

if [ ”d $USERS/$1 ] 
then 

echo "Home directory already exists." 
exit 1 
f i 

if grep \"$1\: /etc/passwd >/dev/null 
then 

else 

echo "No password entry." 
exit 1 
fi 

mkdir $USERS/$1 
chown $1 $USERS/$1 

Is -Id $USERS/$1 
Is -la $USERS/$1 

echo "Remember to add the new user to a group." 


The Step-by-Step Method 

If you decided not to use the “makeuser” script, here is a step-by-step procedure for 
accomplishing the same task. The following procedure assumes that certain files are lo¬ 
cated where they were when the system was shipped. It also assumes that an appropriate 
entry for the new user already exists in the /etc/passwd file. 

1. Create a login directory for the user with the mkdir command by typing: 

mkdir /Msera/user^name | Return | 

where user_name is the new user’s name and the entire path name 
{/uaera/ user^name) matches the login^directory field of the user’s /etc/passwd 
entry. 
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2. Create .profile (or .login for Cshell users) and .exrc files for the user. If the file 
.profile exists in a user’s login directory, the shell attempts to execute that file at 
the end of the login process. As discussed in Chapter 4, this file typically contains 
shell commands and environment variable definitions which customize the user’s 
environment and/or automatically run one or more programs. If the file .exrc 
(also discussed in Chapter 4) exists in the user’s login directory, it is used to map 
terminal characteristics and key definitions for some of the HP-UX text editors. 

3. Because you (the user root) created the new user’s directory and copied the .pro¬ 
file and .exrc files into his directory, you own both his directory and his files. To 
change the ownership to the user, type: 

choWn user^name /users/ user_name \ Retumn 

(where user^name is the user and /users/ user_name is his login directory) to change 
the directory ownership and type: 

chovm user_name /users/ user_name /. [a-z]* | Return | 

(where user_name is the user) to change the ownership of the files. The specification 
/users/ user_name/, [a-z]* matches all the files in the user’s directory that begin 
with a period and are followed by a lower-case letter and then anything else. 

4. Check the ownership and permissions of the user’s directory by typing: 

Is -Id /users/ user_name | Return | 

and check the status of the user’s files by typing: 

Is -la /users/ user_name | Return | 

See the ls{l) entry in the HP-UX Reference for an explanation of the display. 

5. If you are using the group access features available on HP-UX, see the “Creating 
Groups/Changing Group Membership” section in this chapter. 

Whether you used the “makeuser” method or the step-by-step method, the new user is 
now installed on the system. A few optional considerations still bear examination. 
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Some Optional items 

If you are using HP-UX’s group access capability, you may want to add the user to a 
group or change the group ID associated with the user’s files. The user’s group must 
exist in /etc/group and the user must be made a member of that group before the chgrp 
command can be used to change the group ID associated with the user’s files. A user 
may only belong to one group at any given time. For details on these operations, refer 
to the “Creating Groups/Changing Group Membership” section in this chapter and the 
chgrp(l) and group(4) entries in the HP-UX Reference. 

Depending on the needs at your installation, consider using the chmod command to change 
the protection mode of the user’s login directory and files. A commonly used mode value 
is 0755 which provides read, write, and execute (search) permission for the file’s owner 
while providing only read and execute (search) permission for all others. 

If you are adding a terminal for this user, see the “Adding/Moving Peripheral Devices” 
section to set up the terminal and add entries to the /etc/ttytype and /etc/inittab files. 

Setting the New User’s Password 

The new user does not have a password at this point but may log in without one. 
Depending on the security needs at your installation and your own inclination, you can: 

• Ask the user to create a password for himself. 

• Create a password for the user and tell him what it is. 

• Force the user to create a password for himself the first time he logs in to the 
system. 

The procedures for the last two choices are supplied below. 

Creating a Password for the User 

To set a password for the user, first become super-user. Then type: 
passwd user_name | Return | 

and respond to the system’s prompt for a new password; see the passwd(l) entry in the 
HP-UX Reference for details. This will set the new user’s password to the password you 
typed. 


152 The System Administrator’s Toolbox 



Forcing the User to Create a Password 

If you neither want to create a password for the user nor leave it up to him to create 
one, you can set a parameter that forces him to create a password the first time he logs 
in to the system. To accomplish this requires that, in the user’s /etc/passwd entry, the 
password field’s optional “aging” field contains two periods. The optional aging field is 
separated from the password field with a comma (see the passwd(4) entry for details). 
Thus a typical entry for a user v/ithout a passw^ord might be: 

John:,..:105:77:J Jackson,production:/users/john:/bin/sh 

Removing a User from the System 

To remove a user from the system, delete his entries from the /etc/passwd and /etc/group 
files. Then remove the user’s /user directory and his other directories and files (or move 
them to someone else’s directory and change ownership) to release the disk space for 
other users. The easiest way to remove the user’s files is to type: 

rm -r /users/ user_name \ Return | 

Note that this removes all the user’s files and directories. 

If you also wish to remove the terminal associated with that user, delete the terminal’s 
entries from the /etc/ttytype and /etc/inittab files. Refer to the “System Startup and 
Shutdown” chapter in this manual and inittab(4) in the HP-UX Reference for details. 

Suspending a User from the System 

If you wish to keep a user off the system for a time, you can temporarily revoke his 
login privileges by modifying his line in /etc/passwd. If his password is replaced with an 
asterisk (*), he cannot use the system until you delete that asterisk (and then give him 
a new password). The following example illustrates this: 

atilla:*:101:5:Atilla the Hun:/users/atilla:/bin/sh 
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Adding to /etc/checklist 

The /etc/checklist file contains a list of file systems. A file system is an organization of 
files and directories on a disk. When you installed HP-UX, one file system, the root file 
system, was created. You may create several file systems (one per disk) if necessary. 

The format of an entry in /etc/checklist is: 

dev.name blk_dev_name directory type pass.num 0 comment 

where: 


dev.name The device name used by fsck. dev_name must be the character device 

file associated with the file system (for example, /dev/rdsk/lsO rather 
than /dev/dsk/lsO). 

blk_dev_name The block device file name used by mount and umount. 

directory The directory where blk_dev_name is to be mounted. 

type A two-character code for the type of device. The possible values for type 

are: 

rw mount with read/write permission for the file system 
ro mount with read-only permission for the file system 
XX ignore this entry 


pass_num 


0 

comment 


fsck will check the rw and ro type entries in the order you specify. The 
root file system (/dev/dsk/OsO) should always be “1” and it should be the 
only file system set to “1”. Any file system labeled “2” will be checked 
after the root file system. File systems labeled *'3’' will be checked after 
the file systems labeled “2”. If more than one file system is specified as 
the same value, then fsck deals with all of them in parallel if the preen 
option is chosen. This speeds up the time required for fsck if the disks 
are on separate HP-IB interfaces. If pass_num is ommitted or has a value 
of -1, fsck will deal with these entries sequentially. 

This field always has a value of “0”. 

This field is preceeded by a . You can put any comment in this field. 
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The information stored in the /etc/checklist file is useful to the following HP-UX pro¬ 
grams: 


Program 
mount -a 


amount -a 


f sck 


Purpose 

During bootup (via mount -a in /etc/rc), or if you execute the 
command, mount -a, all file systems with a type of rw and ro in 
/etc/checklist will automatically be mounted. 

During shutdown (via amount -a in /etc/shutdown), or if you execute 
the command, amount -a, all file systems with a type of rw and ro in 
/etc/checklist will automatically be dismounted. 

If you execute f sck without providing a list of file systems, all devices 
in /etc/checklist of type rw and ro will be checked. 


The example /etc/checklist file in Figure 5-1 will cause the following to happen at 
bootup: 

• fsck will check both the /dev/rdsk/OsO and the /dev/rdsk/lsO file systems, fsck 
will ignore all xx entries. 

• All entries with type rw or ro will be mounted. In this example, /dev/dsk/lsO will 
be mounted on the directory /usr with read/write permission. This is accomplished 
automatically at bootup, using the mount -a command in the /etc/rc file. 


/dev/rdsk/OsO /dev/dsk/OsO / rw 1 0 #root 

/dev/rdks/lsO /dev/dsk/lsO /usr rw 2 0 #7945 

Figure 5-1. Example /etc/checklist File 

If you are temporarily removing a disk from the system, you should invalidate the entries 
for that disk by changing the disk’s type to xx. 
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Backing up and Restoring the File System 

Backing up your system means copying your system’s files onto a backup medium, such 
as cartridge tape. You can use this copy to recover lost data if there is a hardware failure, 
a system crash, or if you accidentally remove or corrupt a file. Backups can be made on 
cartridge tape, flexible disk, or 9-track tape. Recovery procedures are also detailed in 
this section. 

To minimize the chance of loss, backups should be stored at a different location from 
the main file system. “Data safes”, specially designed air-tight, water-proof containers 
for mass storage media, are available from many computer accessory manufacturers. If 
a file or the entire file system is lost or destroyed, you can recover by restoring the latest 
version of your system backup. 

The backup script (/etc/backup) can be used to do either a full or an incremental backup. 
You can customize the script as explained later in this chapter. If you use 9-track tape, 
you must modify the backup script. 


NOTE 

If you have just updated your system from an older version of 
HP-UX you will need to move the new backup script from the 
/etc/newconfig directory to the /etc directory. 


Backup Strategies and Trade-offs 

The method, frequency and extent of the backup operation depends on how much you 
use your system and how much data you feel you can afford to lose. 

Daily Archive Backups 

One backup strategy is to make complete backups of the file system on a daily basis. A 
complete backup is often called an archive backup. Restoring the file system from a full 
archive backup consists of restoring the most recent backup tape or flexible disk. While 
relatively expensive in terms of media, system resources and the time required to make 
full daily backups, the time and effort spent recovering the system is minimal. 
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Incremental Backups 

An incremental backup contains only files that have changed since the last archival 
backup. Incremental backups almost always require less time and less backup media 
than archive backups. 

Mixing Archive and Incremental Backups 

Hewlett-Packard recommends the following backup schedule: 

• full archival backup weekly or biweekly 

• store the backup at least 2 weeks 

• daily incremental backup 

• take an archive backup and store it in a permanent archive monthly. 

You should continue to make incremental backups until: 

• one or two weeks have passed since the last archive backup (if you are maintaining 
an archival schedule); 

• the size of the backups becomes unwieldy (for example, larger than one tape); or 

• you feel it is necessary to create a new archive backup for any reason. 

Suppose, for example, that you make a complete backup of the file system on Monday 
and make incremental backups on Tuesday and Wednesday. Each incremental backup 
contains only those files that have changed since Monday. Further assume that, on 
Thursday, the file system is destroyed. The file system may be reconstructed by first 
restoring Monday’s archival backup of the file system and then restoring the files from 
Wednesday’s incremental backup. Note that the file system is now restored to the end 
of Wednesday’s incremental backup. All work not on a backup has been lost. 
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Things to Consider about File System Backups 

There are several things to think about when backing up your system, particularly the 
first time. 

• What media will I use to perform the backup? 

• What device should I back up to? 

• Where is the backup script? 

• Do I need to modify the backup script? 

• When should I perform my backup? 

• Where will errors be logged? 

What Media Will I Use to Perform the Backup? 

Using the script provided with the system (/etc/backup), you can back up your system 
onto cartridge tape or 9-track magnetic tape. 

Since you must install HP-UX from cartridge tape, you probably already have a cartridge 
tape drive. However, since all UNIX systems can talk to 9-track magnetic tape, you might 
perform a backup onto magnetic tape simply so other systems can read the tape (that 
is, for file transfer). 

Cartridge tape is the recommended backup media because it is easy to store and it is 
easy to retrieve information from. A cartridge tape holds 16 Mbytes on a 150-foot tape 
or 67.5 Mbytes on a 600-foot tape. 

Nine-track magnetic tape is the most expensive backup media, but if you invest in a 
magnetic tape drive that writes 6250 bpi (bits per inch), you will be able to store more 
data per tape than with any other option. (A 2400-foot magnetic tape written at 6250 
bpi will hold approximately 140 Mbytes of data.) 800 or 1600 bpi 9-track tapes hold less 
per tape than cartridge tapes. With the new ftio command backups to 9-track tapes 
are faster than before. Refer to the ftio(l) entry in the HP-UX Reference. 

What Device Should I Back Up to? 

You must choose a device file that is associated with the chosen backup drive. The 
program provided for backing up your system (/etc/backup) uses, as a default, the device 
you used during installation or your last update. This device file name is /dev/update. src. 
If you do not want to use this device you may edit the backup script to change the default 
device or you may change it interactively when you run backup. 


158 The System Administrator’s Toolbox 



Where Is the Backup Script? 

The steps listed under “Performing a System Backup” assume the backup script is in 
the /etc directory. On a newly installed system (not an update), the scripts will be in 
the /etc directory, therefore do nothing here. 

On a newly updated system (for example, you just updated your system from 5.1 to 5.2), 
the scripts may be in the /etc/newconfig directory. The customizing part of updating 
your system checks to see if the file exists in the /etc directory. If the file already exists 
in the /etc directory, the customize scripts will not overwrite the file. 

If the scripts are left in the /etc/newconfig directory after the update you should move 
them to the /etc directory. If you have made any changes to your old version of the 
backup script you may wish to implement the changes in the new version. The scripts 
have changed for the 5.2 release of HP-UX. If you use an older version of the script you 
should follow the instructions in the previous revision of the manual. 

Do I Need to Modify the Backup Script? 

In general you do not need to modify the backup script. In a few cases you must modify 
the script, and in several other cases you may want to modify the script. This manual 
will not discuss the optional modifications. However, if you wish to read through the 
script, it has many helpful comments. In a script file, everything on the line which follows 
a pound sign (#) is a comment. 

You must modify the script if: 

• You are backing up to 9-track magnetic tape. 

To prepare to backup, you must edit the /etc/backup script and replace these lines: 

cpio -OCX I 

tcio -o Sdest 

with this line: 

cpio -ocBx > $dest 

or the line: 

ftio -ocxM $dest 

• You are using a cartridge tape drive with an autochanger. 
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If you will use an autochanger cartridge tape drive (such as the HP 35401) you must 
edit the /etc/backup script and add the -1 and -n options to the tcio command, 
for example, if you wish to use up to four tapes, starting with tape one, your new 
tcio command line will look like this: 

tcio -o '1 1 -n 4 $dest 

The autochanger must be in selective mode for the autochanger option to work 
properly. For additional details on the autochanger options, refer to the tcio entry 
in section 1 of the HP- UX Reference. 

When Should I Perform My Backup? 

To make sure all files are correctly backed up, your system should be shut down to 
run-level s for backups. This is to prevent any programs or users from accessing and 
modifying files during the backup. If files are modified during backup, file consistency 
cannot be maintained. 

Backups on cartridge tape are generally performed at night, using cron. The section 
called “Performing Backups Automatically” discusses this. 

Where Will Errors Be Logged? 

The /etc/backup script will write (log) the following information to the file 
/etc/backuplog: the start and finish times of the backup, the number of blocks copied, 
and any error messages that may have occurred during the backup. Information and 
messages written to this log file are appended onto the end of the file. 

Performing a System Backup 

The following procedure will back up your system onto cartridge tape (or magnetic tape 
if you have modified the /etc/backup script to write to a magnetic tape device). 

1. Login as the super-user root. If you are not the super-user you will have problems 
copying files that you do not own or have permission to access. 

2. Execute the shutdown command by typing: 

shutdown 0 

For more information on the shutdown procedure, refer to the section “Shutting 
Down the System” in Chapter 4. 

3. Mount all file systems you wish to back up. 
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The shutdown command stopped all processes and unmounted all file systems in the 
/etc/checklist file. If you wish to back up information on those file systems you 
must now re-mount them by typing: 

devnm / | setmnt 
mount -a 

This creates the /etc/mnttab file and mounts all file systems in /etc/checklist. 

4. Insert the backup media. 

If you are backing up onto cartridge tape, and you have the autochanger tape unit, 
it must be in the selective mode to use the autochanger options from tcio. 

5. Change to the root directory by typing: 

cd / 

6. Type the backup command line. 

a. If you are doing an archival backup, type: 

/etc/backup -archive 

b. If you are doing an incremental backup, type: 

/etc/backup 

7. Verify or type in the correct destination device path name. 

You will get a message similar to: 

backing up to /dev/update.arc 

enter new device name to change the backup destination, 
this will timeout in 1 minute 

The device file, /dev/update.src, is the file you installed or updated from. This is 
the device file associated with the source media on your install or update. If you 
are using that device for your backup, either press I Return | or let the program time 
out. 

If you wish to back up to some other device, type in the device file name (make 
sure it is the character special device rather than the block special device). 

If you don’t know, you can exit the backup procedure by typing | Ctrl 11 D | . 
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The backup procedure will now check the file name. It will verify that the device 
file is the character special file, and that it already exists. If it doesn’t exist, you 
will get the following message: 

Warning: you may be backing up to a file 

If you get this message, exit the backup procedure (by entering | CTRL | | D | ) and 
check the device file name. 

During a backup to cartridge tape, if the end of the cartridge tape is reached during 
the backup process, it prompts you to insert a new medium with the following 
message: 

tcio: to continue, type new device name when ready, return implies 
same device 

When this occurs, change the backup medium and press the | Return | key. The 
backup process will then continue. 

If you have a cartridge tape autochanger you do not need to respond to this message. 

8. When the backup has finished, remove the backup media. 

9. Label the backup media with the date and the type of backup (archive or incre¬ 
mental) and store it in a secure place. 

10. Unmount your file systems. This must be done before you change directories or 
start processes. To unmount your file systems, enter: 

unmount -a 

11. Check the file system by typing in: 

fsck -P 

For more information on fsck refer to “Using the FSCK Command” in Appendix 
A. 
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12. Return to your normal run-level. You can either reboot or you can use the init 
command: 


a. to reboot to the normal run-level, enter: 

reboot 

b. To use the init command, enter: 

rm /etc/mnttab 
init 2 

13. Examine the information and messages sent to the file, /etc/backuplog to determine 
if any errors occurred during the backup process. 

Backing Up Selected Files onto Flexible Disk or Magnetic Tape 

A typical device file name for a flexible disk drive is /dev/rdsk/lsO. If you created a 
special device file for your drive with some other name, or if you are backing up to 
magnetic tape, replace /dev/rdsk/lsO (in the following examples) with the appropriate 
character special device file name. 

If you are backing up selected files, do the following: 

1. Go to the directory containing the files you wish to back up: 

cd directory_name 

2. Use the cpio command as follows: 

a. To back up all files and subdirectories from the current directory, type: 

find . -print I cpio -ocBx > /dev/rdsk/lsO 

b. To back up all files in your current directory, type: 

Is I cpio -ocBx > /dev/rdsk/lsO 

c. To back up selected files in your current directory and subdirectories, type: 

Is file^name dir_name/file_name I cpio -ocBx > /dev/rdsk/lsO 

The file names should be separated by blank spaces. If your files are in 
different directories, you can specify relative path names for your file names. 
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Backing up Selected Files onto Cartridge Tape 

During system installation or update, a character special device file, /dev/update. src, 
was created, which is associated with the cartridge tape you used to install HP-UX. If 
you created a special device file with some other name, replace /dev/update. src (in the 
following examples) with the appropriate character special device file name. 

If you are backing up selected files, do the following: 

1. Go to the directory containing the files you wish to back up: 

cd directory_name 

2. Use the tcio and cpio commands as follows: 

a. To back up all files and subdirectories from the current directory, type: 

find . -print I cpio -ocx I tcio -o /dev/update.src 

b. To back up all files in your current directory, type: 

Is I cpio -OCX I tcio -o /dev/update.src 

c. To back up selected files in your current directory and subdirectories, type: 

Is file_name dzr_name/f ile^name I cpio -ocx I tcio -o /dev/update. src 

The file names should be separated by blank spaces. If your files are in 
different directories, you can specify relative path names for your file names. 

Restoring the System 

Restoring the system means using your backups to put lost files back on the system. 
There are three scenarios where you might need to restore your system: 

• Someone on the system lost a file (perhaps accidentally deleted it) and needs a 
copy. 

• You can boot the system, but the file system is destroyed to the point of not being 
able to access files and programs. 

• Your file system is so badly damaged you can’t even boot the system. 

Each of these scenarios are described below. 
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Restoring Selected Files 

When you need to restore selected files onto your HP-UX system, you should do the 
following: 

1. Log in as either the super-user, root, or as the file’s owner. 

2. Write protect the tape on which your backup is stored. 

3. Change directories. You must reside in the correct parent directory before restoring 
files. The correct parent directory is the same as the directory you were in when 
you created the backup. If you are restoring from an archive or incremental backup, 
you must be in the root (/) directory. If you are restoring files from a selected file 
backup, you must be in the directory where you performed the backup. 

4. Place the cartridge tape in the mass storage device and wait for the cartridge tape 
drive’s conditioning sequence to complete (that is, wait for the busy light to go off 
after putting the tape in the drive) before continuing with this process. 

If you wish to restore a single file (or several files), and you are restoring from 
a multiple-cartridge tape backup, you can list the files on the media with the -t 
option to cpio. 

5. Once the backup medium is ready, enter one of the following command forms to 
copy the files: 

For 9-track magnetic tape, type: 

cpio -iBcdmux [patterns] < speciaLfile 

For cartridge tape, type: 

tcio -i speciaLfile I cpio -icdmux [patterns] 

Note that speciaLfile is the name of the character special device file associated 
with the backup device (usually /dev/update.src, /dev/rmt/Om, or /dev/rct/cO). 
[patterns] is an optional parameter used to specify which files to recover. If you 
wish to recover all the files, do not specify a pattern. If you wish to recover specific 
files, list them (separated by a blank space) where you see [patterns]. 

Patterns may include wildcard characters like * and ? if they appear inside apos¬ 
trophes. for example the pattern ’*/mail/** will restore all the files in the mail 
directory. 

If you know which media the file is on (you used the -t option in step 4), you can 
insert the correct media and use the R option in cpio. The R option allows you to 
resync the headers so you do not need to read through all the media. 
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Restoring the File System When You Can Still Boot the System 

If you need to restore the system due to major problems, and the system is still function¬ 
ing, log in as the super-user root and run the shutdown and f sck commands as referenced 
previously in the section “Performing a System Backup”. In many cases, the fsck com¬ 
mand can repair even serious problems in the file system. Often, lost files will show up 
in the /lost+found directory after running fsck. 


NOTE 

Any programs or files that are being run or used on the system 
while restoring the system will not be updated. For example, if 
the root user runs the shell, /bin/sh, then /bin/sh will not be 
restored from the tape. You must copy /bin/sh to someplace else. 


To restore the entire file system: 

1. Log in as the super-user, root. Follow the procedure in “Becoming the Root User” 
in this chapter. 

2. Write protect the tape or flexible disk on which your backup is stored. 

3. Change directories. Since you are restoring from an archive or incremental backup, 
you must be in the root (/) directory. 

4. Place the backup medium in the mass storage device. If your backup goes across 
several tapes, make sure you insert the first one. Wait for the cartridge tape drive’s 
conditioning sequence to complete before continuing with this process. 

5. Once the medium is ready, enter one of the following command forms. 

For 9-track magnetic tape, type: 
cpio -iBcdmuvx < special_file 

For cartridge tape, type: 

tcio -i special^file I cpio -icdmuvx 

Note that speciaLfile is the name of the character special device file associated with 
the backup device (usually /dev/update. src, /dev/rmt/Om, or /dev/rct/cO). 
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Restoring the File System When You Can’t Boot the System 

If the entire file system is destroyed or if the system is in such poor shape that the cpio 
command will not function properly, then one of two options is available. 


NOTE 

If your file system is destroyed, you should take the time to un¬ 
derstand the circumstances which caused the problem so you can 
prevent having to repeat this procedure. 


Option One If you set up a recovery system after your initial installation (using 

the procedures described in “Creating and Using a Recovery Sys¬ 
tem” in Chapter 5), you can boot your system and rebuild your file 
system from your backup recovery system. The recovery system is a 
functional HP-UX system on cartridge tape or flexible disk. 

Option Two If you have not created a recovery system, your system must be 

re-installed from the original distribution medium. Follow the in¬ 
structions in the installation manual to re-install the system. If you 
have updated your system since you installed, you will also have to 
do one (or more) updates before you begin restoring files. 

Once you have re-installed the original system and it is operating 
properly, use the forms of the cpio and tcio commands given in the 
previous section (“Restoring the File System When You Can Still 
Boot the System”) to copy (restore) the most recent archive and 
incremental backup(s) from the backup device to the system’s root 
device. 

System Restoration and Shared Files 

In general, the system cannot write to a busy file. A file (pure Series 500 executable 
code) is “busy” if the file is open or is marked as shared and being executed with exec. 
(Shared files are discussed in the “Concepts” chapter.) Thus, files being used during a 
system restoration — particularly /bin/cpio — should not be shared files. If they are 
marked as shared, they may not be recovered from the backup. 
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Diagnostics 

One of the characteristics of incremental backups is that they depend heavily on the 
system clock. Both the current time and date as well as the time and date associated 
with the file being used as a reference point for the backup (such as /etc/archivedate) 
have to be reasonably accurate to insure useful incremental backups. Always check, and 
if necessary reset, the clock (using the date command) if the system has been powered 
down for any reason or if a check of the clock shows any appreciable amount of inaccuracy. 


Performing Backups Automatically 

Incremental backups can be performed automatically by using the crontab command 
to schedule backup (where it gets executed by the cron “clock daemon”). Refer to the 
cron(l) and crontab(l) entries in the HP-UX Reference. 

To add automatic backups to your system, perform the following: 

1. Login as the super-user, root. 

2. Add the following line to your existing cron information file: 

55 23 * * 1-5 /etc/backup 

If you don’t know what your existing cron file is named, you can create a copy of 
it by executing: 

crontab -1 > new_cron_file 
then add the new line to it. 

3. Use the crontab command with the file’s name as an argument. For example, if 
your cron information file is called croninfo, enter: 

crontab croninfo 

This creates a file, /usr/spool/cron/crontabs/root, which overwrites the existing 
file, /usr/spool/cron/crontabs/root. cron will automatically do a backup at 11:55 
p.m. 

When running backups with cron, there is no way of knowing if the system is inactive 
without logging users off. Choose a time when you think no one will be working. Send 
a message to all users requesting them to log off. The backup script notifies all current 
users when the backup begins. 
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If you run backups from cron, perform the following steps: 

1. Assign the backup script’s error output device to a special file associated with a 
printer (default is /dev/lp). 

2. Every morning after a backup: 

a. Examine the information and messages listed to the printer during the previ¬ 
ous night’s backup process. 

b. Remove, label and store the backup medium. 

3. Every evening before a backup: 

a. Be certain that the printer associated with the backup script’s error output 
device is on-line. 

b. Install a blank backup medium. 
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Changing a Password 

The “Adding/Removing Users” section in this chapter discusses creating passwords for 
users. This section discusses how either a user or the system administrator may change 
passwords. 

Any regular user on the system may change his own (but no one else’s) password by 
typing: 

passwd 

The passwd command prompts for the existing (old) password before allowing the user 
to continue. Once the correct old password is entered, the command prompts for a 
new password. Enter at least 6 characters and/or digits of your choosing. At least 2 
characters must be alphabetic, and at least 1 must be a numeric or special character. 
Actually, fewer characters may be used but they must be entered three times before 
the system will accept them (this is only true if you are super-user). Note that control 
characters like those generated by | Back space | are accepted but sometimes difficult to 
remember. The password is not echoed on the screen (for security purposes). The 
command then prompts you to re-enter the password to confirm it. Do so and, if the two 
entries match, the program accepts the new password. If the two entries do not match, 
you will be prompted to enter it twice again. It takes approximately 15 seconds for the 
system to install the password. 

Users will occasionally create passwords for themselves which they cannot remember. 
Once a user has forgotten his password, he cannot log in to the system and will probably 
come to you, the system administrator, for help. Because only the encrypted form of the 
password exists in /etc/passwd, even you cannot determine the user’s password, hence 
you must assign the user a new password. 

To change a user’s password, become super-user and type: 
passwd user_name 

where user_name is the user's login name. You will be prompted for the user's new 
password. Only the super user may use this method for changing a password. 

If you change the password for the user root you may want to write down the password 
and keep it in a secure place. If this password is lost or forgotten no one can log in as the 
super-user and you will either need to completely re-install your system or will need to 
use your recovery system. Note that a complete re-installation of the system will destroy 
all the files on the disk. 
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Changing and Creating System Run-Levels 

A run-level is a state in your system where a specific set of processes are aiiowed to run. 
This set of processes is defined in the /etc/inittab file for each run-level. You can define 
up to six run-levels. 

Most systems will use only the two run-levels shipped with your system: run-level 2 
for normal multi-user mode, and run-level s for system administration. You can move 
between these two run-levels using the shutdovm and reboot commands. This section is 
written for the system administrator who requires more than the two default run-levels. 

One of the tools you need as the system administrator is the ability to move properly 
from one system run-level to another. Also, you may find it useful to create new system 
run-levels for particular tasks or applications specific to your installation. The material 
in this section covers some protection issues associated with these capabilities followed by 
guidelines for changing the run-level of the system and creating new system run-levels. 

As discussed in the “System Startup and Shutdown” chapter in this manual, the system 
administrator (or anyone with the root user capabilities) may change the system’s run- 
level by executing the init command. Also, anyone having write permission to the file 
/etc/inittab can create new run-levels or re-defme existing run-levels. Even if this user 
lacks the capability to invoke init to enter a modified run-level, his ability to re-define 
existing run-levels in /etc/inittab is potentially dangerous to your system. Make sure 
that the aforementioned permissions are correct. 

If you purchased a single-user system, the system was shipped to you such that run-level 
s uses only the system console and run-level 2 uses both the system console and a single 
UUCP modem (for data communication with other HP-UX and/or UNIX systems). You 
can create other run-levels on this system but you cannot add any other users. Adding 
getty entries to run-level 2 on a single-user system has no effect other than to waste a 
large amount of processor time. If yours is a single-user system, note that much of the 
following material applies primarily to multi-user systems. It should be clear from the 
context which of the discussed features apply to single-user systems. 
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Changing the System’s Run-Level 

Many of the system maintenance tasks you perform as system administrator require 
the system to be in the system administration run-level (run-level s). When the HP-UX 
system is first booted/powered up, it comes up in run-level 2. The system administration 
run-level may be entered by executing the shutdown command or the init command. 
These recommended entries are described in more detail in the ‘‘System Startup and 
Shutdown” chapter. 

In the system administration run-level (run-level s), the only access to the system is 
through the system console by the user root. At this point, the only processes running 
on the system will be the shell on the system console, and processes that you invoke. 
Commands requiring an inactive system can now be run. One such command is fsck 
whose multiple passes and use of redundant information in the file system require a static 
system. 

The following is a general procedure for changing the system from one run-level to an¬ 
other. You must be logged in as the super-user to change the system’s run-level. 

1. If any users are on the system, ask them to log off before you change run-levels. 
Changing to another run-level while users are logged on will kill (terminate) their 
processes if the run-level you are moving to does not contain explicit rstate entries 
in /etc/inittab for their getty. Use the write or wall commands to communicate 
with the users. Note that the wall (write all) command immediately sends your 
message to the terminal of each user on the system and, in the process, interrupts 
whatever they are doing (but does not stop execution); avoid using wall unless you 
feel it is necessary. 

If the differences in the new and old run-levels are minor enough (for example, the 
addition of a printer), it may not be necessary to ask users to log off. 

2. After users are off the system as necessary, force the system to write the contents 
of its I/O buffers to the file system by typing: 

sync 

It is a good idea to repeat the sync command a second time. This is recommended 
because, after sync executes the file system primitive sync (2) and returns, the 
writing of the I/O buffers has been scheduled but may not have yet taken place. 
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3. Next, change to the desired run-level by typing: 

/etc/init new_run_level 

where new_run_level is the number of the run-level you wish to enter. It is assumed 
that the run-level you are entering contains appropriate /etc/inittab entries to kill 
any outstanding user processes, if those processes should not be present in the new 
run-level. 

When taking the system from the multi-user run-level (run-level 2) to the system admin¬ 
istration run-level (run-level s), use the shutdovm command instead of init s to change 
the system’s run-level. The shutdown command performs certain operations not other¬ 
wise performed. See the shutdown(lM) entry in the HP-UX Reference or the ''Shutting 
Down the System” section in Chapter 4 for a more complete description of shutdown. 

Also, be aware that a cron process is initiated only the first time the system enters 
run-level 2. 

Re-reading /etc/inittab 

If you wish to make a change to the current run-level, such as adding a new getty, 
the system will need to re-read /etc/inittab before it will execute the new command. 
To accomplish this, execute /etc/telinit. Refer to the init(lM) entry in the HP-UX 
Reference for more information. 

Creating New System Run-Levels 

You can create new run-levels if you find it useful but do not re-define run-level 2. It is 
acceptable to make certain, suggested modifications to run-level 2 (such as the addition 
of more getty entries to /etc/inittab). Before creating a new run-level, make a copy of 
the original /etc/inittab file (using the cp command) and save the original version of 
the file under a different name (such as /etc/orig_inittab). If anything goes wrong, you 
will still have a relatively untouched version of the file. 
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To create new rnn-levels, use one of the HP-UX text editors to make entries in 
/etc/inittab. These entries will define how you want the system to operate in its new 
run-level. Each one line entry in /etc/inittab should contain: 

• a two-character id used to identify a process or process group; 

• a list of run run-levels to which each entry applies; 

• an action to be performed, such as respawn; 

• the command that will be executed when that run-level is entered. 

Refer to init(lM) and inittab(4) in the HP-UX Reference for a more complete description 
of inittab’s run-level entries. Once /etc/inittab contains all of the entries you want for 
the new run-level, save the file and exit the text editor. As before, warn all users to log 
off the system and follow the other procedures in the “Changing the System’s Run-Level” 
section above before you change run-levels. 

In a few cases, such as when a newly created run-level closely matches an existing run- 
level (i.e., the differences between the two are trivial), you can move freely between 
run-levels as long as entering the new run-level does not kill (user or system) processes 
that may have begun in the previous run-level. If the new run-level is not specified in the 
rstate field of the /etc/inittab entry for their getty, the process will be killed. Watch 
for side effects however. Consider the case where a user logs off, you then change run- 
levels (from say, run-level 2 to run-level 4) and when the user attempts to log back in, he 
cannot because an /etc/getty entry does not exist for him in your run-level 4 definition. 

Whenever the system enters the newly-defined or created run-level, its actions are similar 
to those described in the “System Boot” section (of the “System Startup and Shutdown” 
chapter in this manual) except that the commands executed are those identified by the 
new run-level number. Some files, such as /etc/rc, have no entries for run-levels other 
than run-level 2. The system boot and login processes occur more or less as described 
(in that same chapter). 
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Example /etc/inittab 

The following is an example /etc/inittab for a system that contains a system console 
and four terminals. Run-level 2 is a multi-user run-level, with a getty on every terminal. 
Run-level 3 is a test run-level, with a getty on both the system console and the system 
administrator’s terminal (/dev/ttyOl) and “kill” entries for the other terminals. This 
run-level could be used by a system administrator who preferred to work from his own 
terminal rather than from the system console. The system console could also be moved 
by executing init from another terminal. 

is:2:initdefault: 

St:rsysinit:stty 9600 clocal icanon echo opost onlcr ienqak ixon icrnl 
ignpar < /dev/systty 

bl:ibootwait:/etc/bcheckrc </dev/syscon >/dev/syscon 2>kl #bootlog 

be::bootwait:/etc/brc l>/dev/syscon 2>&1 #bootrun command 

Ip::off:/bin/nohup /bin/sleep 999999999 < /dev/lp k stty 9600 < /dev/lp 

rc::wait:/etc/rc </dev/syscon >/dev/syscon 2>&1 #run com 

pf::powerfail:/etc/powerfail l>/dev/con8ole 2>&:1 #power fail routines 

CO::respawn:/etc/getty console H 

01:23:respawn:/etc/getty ttyOl H 

02:2 :respawn:/etc/getty tty02 H 

03:2 :respawn:/etc/getty tty03 H 

04:2 :respawn:/etc/getty tty04 3 
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Changing the HP-UX Environment Files 

The system boot and login processes provide many opportunities to customize the envi¬ 
ronment in which your system operates. Customization is achieved primarily by altering 
the contents of one or more files known as environment files. The following list summa¬ 
rizes the files that you may want to alter and identifies the types of changes you may 
want to make. Use these suggestions in conjunction with Chapter 4, the section ''System 
Startup Functions”, to determine which files to modify. 


NOTE 

The system may not boot if some entries in /etc/inittab, /etc/rc, 
and /etc/passwd are modified. The parts of these files that are 
shipped should not be changed, though additions can be made as 
necessary for terminals, commands, and users. You should check 
the /etc/passwd and /etc/group files with the pwck and grpck com¬ 
mands after making any changes. 


/etc/inittab 

This file contains entries for the different run-levels (supplied or created) on your system. 
Refer to "Changing and Creating System Run-Levels” in this chapter and to the "System 
Startup and Shutdown” chapter. 

/etc/rc 

This shell script defines miscellaneous actions to be taken after system boot or mainte¬ 
nance (following a shutdown). This script typically contains commands to: 

• Mount file systems via the mount command. 

• Start the cron program running. 

• Start the line printer spooling system (if configured). 

• Clean up any logging files. 

• Start System Accountings (refer to Chapter 6 in this manual). 

• Set your system’s nodename. 

• Run expreserve to preserve editor files (refer to the ex{l) entry). 

• Turn on LAN. 
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/etc/passwd 

This text file identifies the user name, real user and group IDs, home (login) directory, 
and execution command for every valid user on the system. The execution command is 
the command executed when the user correctly logs in. You must add an entry to this 
file for each new user who is added to your system. Refer to “Adding/Removing Users” 
in Chapter 5. 

/etc/group 

This text file identifies the users that form a group. It associates group IDs with group 
names. It also contains a list of users and associates those users with a group name and 
a group ID. Refer to “Creating Groups/Changing Group Membership” in Chapter 5. 

/etc/motd 

This text file contains messages that are printed to each user when he logs in. If you have 
a message that you want to communicate with every user (such as a message specifying 
a new system update), write the message in this file by using your favorite text editor. 
As each user logs in, the message will be printed (assuming that the scripts /etc/profile 
and /etc/csh.login are not modified to remove the command that prints /etc/motd). 

/usr/news 

This is a directory owned by the user root. It is shipped as an empty directory and can be 
used by you to communicate with users on the system. You can also change the directory 
permissions to allow any user to put messages here. Place any message you want in a file 
contained in this directory. If there is a news command in either the file /etc/profile, 
in $H0ME/.profile or $H0ME/.login (the user’s personal version of .profile), the file you 
placed in the /usr/news directory will be announced when the user logs in. Depending on 
the options used with news, a user only receives the message once. Refer to the news(l) 
entry in the HP- UX Reference for details. 
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/etc/profile or /etc/csh.login 

These shell scripts are automatically executed for users upon logging into their 
shell:/etc/prof ile is executed for users logging into the Bourne shell and /etc/csh.login 
is executed for users logging into the C shell. This is an ideal location to place commands 
that each user is required to execute. For example, you may want every user to read the 
message of the day file (/etc/motd) since it contains information that each user should 
see before beginning her work. This is accomplished by placing the statement: 

cat /etc/motd 

in the /etc/profile or /etc/csh.login shell scripts. These scripts are also an ideal 
location to define and export default environment variables (such as PATH and TZ) in 
case the user does not set them in his .profile shell script. 

/etc/utmp 

This is a binary file that contains a list of currently logged in users and some system 
startup information. It is automatically created by the system and is used by the who 
command. 

/etc/wtmp 

This is a binary file used by the system to keep a history of logins, logouts, and date 
changes. The contents of this file are accessed with the last command. To create this 
file, type: touch /etc/wtmp. 

/etc/btmp 

A binary file which, if it exists, is used by the system to keep track of bad login attempts. 
You must explicitly create this file to use this feature. The contents of this file are accessed 
with the lastb command. 
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/etc/securetty 

A text file which, if it exists, specifies the tty files on which the root user can log in. 
You must explicitly create this file and place the tty device file names in it to use this 
feature. The entries should be the tty device file name but not the path name. The file 
can contain more than one entry but only a single entry per line. If you do not explicitly 
create this file, the user root may log in on any tty device. Note that this security feature 
does not restrict a normal user from using su to become the superuser on any device. 
Here is a typical /etc/securetty file with two entries: 

console 

tty05 

$HOME/.profile, $HOME/.cshrc, $HOME/.login 

These shell scripts are executed at the following times: 

• $H0ME/.profile (Bourne shell) is executed each time the user successfully logs in 

• $HOME/.cshrc (C shell) is executed each time a new C shell is started. A new C 
shell is started each time the user successfully logs in, and each time the user starts 
a new C shell, such as using the shell escape feature of vi. 

• $H0ME/ . login (C shell) is executed each time the user successfully logs in, but after 
$H0ME/. cshrc is executed 

For example, they may include a definition of the default shell prompt (the PSl and PS2 
environment variables in the Bourne shell, prompt in the C shell), the default search path 
(the PATH environment variable), and some editor information (the EXINIT environ¬ 
ment variable). It also generally includes the execution of one or more commands such as 
the export command—to export environment variable definitions, the who command—to 
identify who is logged in on the system and the mail command—to automatically display 
mail that has been received. 

Changes made to the .profile script do not go into effect until the script is executed. By 
typing the following in your current shell, .profile or .cshrc will execute in the current 
environment: 

. .profile # In the Bourne shell 

source .cshrc # In the C shell 
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$HOME/.exrc 

This file maps terminal characteristics and sets up new key definitions so that features 
like arrow keys can be used with the ex family of HP-UX editors (vi, ex, etc.). The 
file . exrc must exist in the user’s home directory (SHOME) to use these features. The 
editor searches for $H0ME/ . exrc and, if it exists, uses the definitions to create extra editor 
features. 

Note that the . exrc file is functional only if the EXINIT environment variable is not de¬ 
fined. EXINIT can be defined and exported from either /etc/profile or $H0ME/ .profile. 
The .exrc file serves a function similar to EXINIT. Refer to the appendix to “The vi 
Editor” article in the HP-UX Concepts and Tutorials manual for further details. 


Note 

Examples of .profile, .login, and .exrc are shipped under the 
names /etc/d.profile, etc. You may find it useful to customize 
these files and provide them to new users by default. 


/usr/lib/terminfo 

This subsystem identifies terminal capabilities for programs such as the vi text editor. It 
defines terminal attributes for all Series 500 models and HP supported terminals. It also 
contains terminal attributes for terminals not supported by Series 500 HP-UX; these are 
provided for your convenience, but Hewlett-Packard does not support their use. 

/etc/checklist 

This text file contains a list of mountable file systems. When no device file specification 
is supplied with the fsck command, fsck performs its checks on the file systems listed in 
/etc/checklist. This file is also used by the system accounting diskusg conunand, and 
the mount, umount, and f sclean commands. 

The file /etc/checklist is shipped with a single device file name: /dev/rhd. This file 
corresponds to the hard disk on which you installed the system and which contains the 
root file system. You should add entries for each additional disk drive containing a file 
system which you want automatically mounted. Refer to “Adding to /etc/checklist” in 
this chapter for more information. 
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/etc/catman 

Executing the catman command expands the nrof f (formatted) versions of manual pages 
(used by the man command) into their “processed” form. Subsequent accesses via man 
use the processed manual page, significantly improving response time. The price for the 
improved speed is disk space—the expanded files wiW use about the same storage space 
as the originals. This doubles the disk usage for manual pages because the original files 
remain intact. By default, running catman causes manual pages in all the /usr/man/manX, 
/usr/local/man/manX, and /usr/contrib/man/manX directories (where X is 0 through 9, or 
1M) to be processed and stored in the corresponding /usr/man/catX, /usr/local/man/catX, 
and /usr/contrib/man/catX directories. If you run catman without the -z option the pages 
are put in compressed form in the corresponding .Z directories. The catman command 
creates the directories if they do not exist. 

You have three alternatives for creating on-line documentation: 

• Create all the processed manual pages by executing /etc/catman with no parame¬ 
ters. This process can take as long as five or six hours to complete so you might 
want to run it in the background and/or at night. 

• Create selected sections of the processed manual pages by executing /etc/catman 
sections (where sections is one or more logical sections in the HP-UX Reference 
such as 1). 

• Do not execute /etc/catman at all. If you create all the /usr/man/cat directories, 
the first time man is executed for any given manual entry, the entry is processed, 
added to the appropriate cat directory, and used in subsequent accesses. 

Use the following script to create the appropriate compressed cat directories: 

cd /usr/man 

for num in 12345678 
do 

mkdir cat$num.Z 
done 

The third alternative is recommended if you can spare some disk space but do not want 
to use any more than is necessary. With this “build-as-you-go” alternative, the system 
only fills the cat directories as manual pages get accessed by man. 

When the processed man pages exist, you can remove the nroff source files and thus 
recover much of the disk space required by the formatted version of the manual. 
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/etc/issue 

This file contains information that is printed by the terminal's getty process prior to the 
login prompt. Messages that identify the computer or provide the system name might 
be stored in this file. 

/etc/csh.login, /etc/rc, and /etc/profile 

These three files need to be edited in order to set the correct date information in the 
environment. The format for setting the time zone environment variable is: 

TZ=XXXHYYY 

where: 

XXX is an alphabetic abbreviation of the standard time zone, usually three let¬ 

ters in length. 

H represents the difference between standard local time and Greenwich Mean 

Time, in hours. Fraction hours are indicated in minutes (for example, 3:30 
for Newfoundland). Negative hours are allowed (for example, -9:30 for 
South Australia). 

YYY is an alphabetic abbreviation of the daylight time zone for your area, usu¬ 

ally three letters in length. YYY may be deleted if Daylight Savings Time 
is not observed in your geographic area. 

Insert or modify the lines in /etc/rc and /etc/profile: 

TZ=XXXHYYY 
export TZ 

Insert or modify the lines in /etc/csh.login: 
setenv TZ XXXHYYY 

For example: 

• In Eastern time zone, use TZ=EST5EDT 

• In Central time zone, use TZ=CST6CDT 

• In Arizona, where Daylight Savings Time is not observed, use TZ=MST7 

For more information pertaining to setting the system clock, refer to the section “Setting 
the System Clock” in Chapter 5. 
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/usr/lib/tztab 

The /usr/lib/tztab file describes when and where Daylight Savings Time (in the United 
States) is in effect. It is implemented by listing the values of the TZ variable, followed byh 
the dates it is in effect. It can be modified to accomodate changes. This file was created 
because of recent U.S. legislation which changed the definition of Daylight Savings Time. 
Refer to tztab(4) for details on modifying this file. 

/etc/ttytype 

This file works with the tset command. Change this file when adding terminals and 
modems to your HP-UX system. This file works with the tset command. Change 
the samples (for example, 300h console) to reflect the true terminal types attached to 
your system. Refer to the section “Adding Peripheral Devices” in this chapter for more 
information. 

/usr/adm/errfile 

This is an ASCII text logging file. The system uses this file to log system errors or 
warnings. Urgent messages are also written to /dev/console. It is created by the system 
and grows without bounds. 
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Communicating with System Users 

The /usr/news directory and the news command provide a way to get brief announcements 
to the system users. The files /etc/profile and /etc/csh.login, unless modified, notify 
each user at login that news exists if /usr/news contains entries. 

More pressing items (such as announcing an upcoming archival backup) can be en¬ 
tered in the message-of-the-day file, /etc/motd. Unless modified, /etc/profile and 
/etc/csh.login print the contents of /etc/motd on a user’s display during login. Keep 
these messages short enough to easily fit on the user’s screen. 

Longer messages or even major documents are best sent with the mail command. Any 
user can send a message to any other user with mail. When activated to send a message, 
the mail command takes the message, flags it with the recipient’s user name and stores 
it in a file. The next time the recipient executes mail, the command informs him that 
he has mail. Most users keep some form of the mail command in their .profile file so it 
will automatically be executed during login. This is done by default when /etc/profile 
and/or /etc/csh.login execute. 

To write to users who are already logged in, use the write or wall commands. Note that 
if a user has executed the mesg command with the -n (no) option, write permission to 
that user’s terminal is denied and the write command will not work. In this case, use 
the wall command. 

When the wall (write all) command is run by the super-user, any user protections are 
overridden; the command immediately sends its message to every user’s terminal, regard¬ 
less of the tasks they are performing. Thus, if you are logged on as the super-user, avoid 
using wall unless it concerns a pressing matter such as an impending system shutdown; 
consider a user’s irritation at receiving an unimportant message while he is editing a file. 
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Configuring the HP-UX Operating System 

HP-UX allows certain operating system related attributes to be configured. These at¬ 
tributes determine the manner in which the system allocates memory, schedules pro¬ 
cesses, and performs file I/O— and thus, the performance of your system. They are 
configured using the uconf ig command. 

Configurable Attributes 

The attributes that you can specify (configure) are: 

• virtual memory device —(vm_device) the mass storage device that is used by virtual 
memory. The default is (00000), which specifies that the default is the root device. 

• cache buffer size —(cache_buf_size) the size (in bytes) of an individual buffer in the 
file system buffer cache. The size of the cache buffer is optimized if it corresponds 
to the block size on your disk volume. The default is 1024 bytes. 

• number of cache buffers —(cache_buLnum) the number of buffers that form the file 
system buffer cache. The default is 0, telling the system to dynamically compute 
the value. 

• read ahead level —(read_ahead_level) the number of “buffers full” of information 
that is read into the buffer cache, when a sequential data access is detected. The 
default is 0, telling the system to dynamically compute the value. 

• swap time^(swap_time) the criterion used by the virtual memory system when 
determining which segment (s) to swap out of memory. When a memory block is 
needed by the virtual memory system, it examines all virtual segments in memory. 
Any virtual segment that has been in memory longer than the “swap time” is eligible 
to be swapped out. If no virtual segment has been in memory longer than the “swap 
time”, the system swaps out the least recently accessed virtual segment. The swap 
time is measured in ticks, with 0 telling the system to dynamically compute the 
default. 

• page size —(page_size) the size (in bytes) of each page, when data is paged in the 
virtual memory system. The default page size is 1024 bytes. 

• page swap time —(page_swap_time) the time a page remains memory resident be¬ 
fore being swapped to disk. The page swap time is measured in ticks, with 0 telling 
the system to dynamically compute the default. 
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• page frame pool size- (vm_pooLsize) the maximum size (in bytes) of the memory 
allocated to the page frame pool (no matter how many memory blocks are free), 
for the virtual memory system. If the default value is 0, a new value is calculated 
to optimize the page frame pool. This value then becomes the default. When you 
ask for default values, the system sets the default back to 0. 

• display memory size—(scroll.pages) the size, in pages (one page of display memory 
equals 24 displayed lines) of the display memory of the Model 520’s display. On 
the HP 98700 ITE, one page is 46 lines of 120 characters. Two pages (48 lines) are 
the default. 

When HP-UX is installed on a Model 520, the computer's display and keyboard 
act as a ‘‘terminal”. As a terminal, it needs memory to hold the information to be 
displayed. Increasing the size of the display memory increases the amount of data 
that can be scrolled on the display. Each page of display memory allocated reduces 
the amount of memory available to the system by about 6 Kbytes. 

If, at power-up, the system does not have enough memory available to allocate 
the requested amount of display memory, the system notifies you and allocates one 
page of display memory. 

The primary status of the Model 520 “terminar' identifies the amount of display 
memory in the “terminal”. In the terminal’s primary status byte, each page of 
display memory allocated appears to be 2 Kbytes, instead of 6 Kbytes, as indicated 
in the preceeding paragraph. 


NOTE 

The display memory size attribute is ignored when HP-UX is run¬ 
ning on a Model 530, 540, or 550 computer. 


• process-per-user maximum (max_proc_per_usr) an integer specifying the maxi¬ 
mum number of processes a single user can have. The default is 500 processes. 
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stack size- (stack.size) the maximum size (in bytes) of a process’ stack segment. 
The default of 0 tells the system to dynamically compute this value. 

interactive time —(interactive.time) the amount of CPU time a process can con¬ 
sume after it has achieved a high priority by accepting input from a keyboard, and 
still be favored as an interactive process. If the process receives no further input 
for a time equal to this parameter’s value, then the process is no longer favored 
as being interactive. The interactive time is measured in “ticks”, where one tick 
equals 10 milliseconds. 300 ticks is the default value. 

message queue IDs (max_num_msgids) the maximum number of message queue 
identifiers (refer to msgctl(2), msgget(2), msgop(2)). The maximum can range from 
5 to 1000, and is rounded down to the closest multiple of 5. The default is 100 IDs. 


message size —(max_msg_size) the maximum size, in bytes, of any single message. 
This can range from 256 bytes to either 65 536 bytes or max_msg_qbytes, whichever 
is less. The default is 8 192 bytes. 

message queue size —(max_msg_qbytes) the maximum number of bytes in a message 
queue. This can range from 256 bytes to either 65 536 bytes or max^msg_space, 
whichever is less. The default is 16 384 bytes. 

total message size —(max_msg_space) the maximum number of bytes in the total 
of all messages in all message queues in the IPC facility. This can range from 256 
to 523 264 bytes. The default is 32 768 bytes. 

semaphore IDs - (max_num_shmids) the maximum number of semaphore identi¬ 
fiers (refer to s€mctl(2), semg€t(2)y semop(2)). This number can range from 5 to 
1000, and is rounded down to the closest multiple of 5. The default is 100 IDs. 
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• shared memory IDs—(max_num_shmids) the maximum number of shared memory 
identifiers. This number can range from 5 to 1000, and is rounded down to the 
closest multiple of 5. The default is 100 IDs. 

• shared memory attaches—(max_num_shm_segs) the maximum number of shared 
memory segments that can be attached to a single process (refer to shmctl(2), 
shmget(2), shmop(2)). This number can range from 0 to 1 000. The default is 10. 

• shared memory size threshold—(max_shm_vsegsz) the upper limit of normal virtual 
shared memory segments. Requests for shared memory segment sizes larger than 
this value will be allocated as paged virtual shared memory segments. This value 
can range from 0 to 523 264 bytes. The default is 16 384 bytes. 

• working set ratio—(work_set_ratio) a decimal value (representing a percentage), 
specifying the minimum number of virtual pages that are guaranteed to any process 
in memory. 

Suppose that you are running a program that, if completely loaded into the system, 
required 1000 pages to be allocated to your partition. Also suppose that the working 
set ratio is 0.04. This guarantees that 0.04x1000 pages, or 40 pages, are mapped 
to your process’ partition. If more pages are available in the page frame pool, 
they may be mapped to your process’ partition as well. However, when pages are 
needed by another partition (and none are available in the page frame pool), you 
are guaranteed that your process’ partition will have at last 4% of its maximum 
need (40 pages). The default is 0.002 (0.2%). 

How to Configure Your Operating System 

The system is configured with the uconfig command. This command writes the new 
configuration values to the specified boot area of the boot device (the mass storage 
device from which the system can be booted). This means that to see the effect of the 
new configuration, you must shut the system down and re-boot (thus loading the kernel 
and the new configuration values from the boot area). 

The operating system being used to modify configuration parameters in a boot area must 
be the same version as the operating system residing in the boot area being modified. 

The file system should be in the system administration run-level (run-level s), and have 
an /etc/f sck command performed before any of the following operations are attempted. 
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To configure the system (with other than the default configuration attribute values), you 
must create a text file. Each line in the text file must have the form: 

id value [# comment] 

where id is a fixed name identifying the attribute you wish to change, and value is the 
new value of the attribute. You can attach comments to any line in the file (and thus 
make a note to yourself of the reason for the value change) by entering the comment 
after a # character. 

A text file containing all configurable parameters and their current values can be easily 
created by redirecting the output of uconfig with no arguments: 

uconfig > this.config 

This file can then be edited to contain the desired parameter values. 

Once the file is created, it can be copied to the boot area of a device with the uconfig 
command. If you change the values in the boot area the system must be rebooted before 
the system will recognize the new configuration. Refer to the uconfig(lM) entry in the 
HP-UX Reference manual. 

Setting the Default Configuration Parameters 

The HP-UX Reference manual describes each id and their range of acceptable values 
for each attribute. Should you accidentally set values that reduce the performance of 
your system, you can restore the system’s default configuration values by simply entering 
(where boot.device is the name of the special file of the boot device): 

uconfig -d <boot_device> 
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Controlling Disk Use 

As system administrator, you should keep track of the amount of disk space available to 
users and the distribution of free disk space across file systems. The following commands 
will help you evaluate your disk use and identify future disk needs. 

• The du command should be executed regularly (weekly or bi-weekly) and the output 
kept in an accessible file for later comparison. This method lets you spot users who 
are rapidly increasing their disk usage. 

The output from du is given in 512-byte blocks. 

• Use the find command to locate large or inactive files. For example, the following 
entry records in the file aging.f iles the names of files neither written nor accessed 
in the last 90 days: 

find / -mtime +90 -atime +90 -print > aging.files 

• Use the df command to list the amount of free disk space on a volume. 

The output from df is given in 512-byte blocks, 

• Use the system accounting package as described in the chapter '‘System Account¬ 
ing” . 

Some files, if present, are written to automatically by certain HP-UX commands (to 
monitor system use and for general house-keeping). Some files are created automatically 
by the commands that require them. Both of these sorts of files are called logging files. 
If not periodically checked and cleared, these files simply continue to grow. 

Here are some typical logging files: 

• /etc/utmp (binary) - current login status. 

• /etc/wtmp (binary) - history of logins, logouts and date changes. 

• /etc/mnttab (binary) - mounted devices (not the official list kept by the system in 
the kernel). 

• /usr/adm/sulog (ASCII) - history of use of the su command. 

• /usr/lib/cron/log (ASCII) - history of actions by cron. 

The only way to avoid logging is to link log files to /dev/null. 
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Creating File Systems 

The HP-UX sysiem provides a coiiiiiiand, sdfinit which "makes" (creates) a nie system 
(structured directory format volume). 

Follow these steps to create a file system for the Series 500 HP-UX system: 

1. Connect the mass storage device on which the file system will exist to your HP-UX 
system. See the “Adding/Moving Peripheral Devices” section earlier in this chapter 
and the installation manuals supplied with your Series e500 computer and/or the 
mass storage device for hardware installation details. 

2. If a special (device) file does not exist for the mass storage medium, create 
one using the mkdev script or the mknod(8) command and the directions in the 
“Adding/Moving Peripheral Devices” section of this chapter. 

3. Once the mass storage device is properly installed, run the media initialization 
utility sdfinit. This utility initializes the medium on which the file system will 
reside. If the medium has been initialized before, you may skip this step. The 
format is: 

/etc/sdfinit /dev/fname blocksize bootsize interleave 

where /dev/fname is special file describing the new media, and blocksize, bootsize, 
and interleave are optional arguments. For more on these arguments, see Chapter 
3 (Concepts) of this manual or the HP-UX Reference manual. 

4. Next, mount the new file system. This is described in the section “Mounting and 
Unmounting Volumes”. The basic steps are: 

# create a directory on which to mount the new file system 
mkdir /mount_directory 

# mount the new file system onto Vmount.directory* 
mount /dev/fname /mount_directory 

where /dev/fname is the name of the special file associated with the mass storage 
medium. 
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7. Create the lost-ffound directory. The program fsck requires that a directory 
lost+found be present on every file system, so that fsck can put stray files there. 
This directory must be created, then it must have some empty entries in it. This is 
accomplished by creating many files (100 will do) and then removing them. This 
creates ^‘slots’’ that fsck can use. Use the following series of commands (where 
mount_directory is the directory on which the file system is mounted as shown 
above): 

# create the lost+found directory 
mkdir /mount_directory/loat-*-found 

# go to the lost+found directory 
cd /mount_dir€ctory/lo3t+found 

# create approximately 100 files 
touch *(cd /bin; Is)‘ 

# remove the files we just created 
rm lost+found/* 

8. Add the new file system to /etc/checklist. 

If the newly created file system is intended as a permanent addition, you may wish 
to modify /etc/checklist so the new file system will be mounted when the system 
is booted. 
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Creating Groups/Changing Group Membership 

A group is denned by a single line in the /etc/group file. Each entry in the file consists 
of four fields, separated by colons. To create a group, edit the /etc/group file and make 
an entry for the group. The general form of the entry for a group is: 

group^name'.password:group^id:memberl, member2, ..., memberN 
The group_name field contains the name of the group. 

The password field is not currently used. However, to prevent non-group members from 
switching to this group (wdth the newgrp command), place an asterisk (*) in this field. 

The group^id field is the unique integer ID shared by all group members. 

The memberl, member2y ..., memberN \\si is composed of the user name of each group 
member; user names are separated by commas. 

To alter a group’s membership, simply modify the membership field for the group entry in 
the /etc/group file. When you are satisfied with the group definition, write the modified 
file to disk and terminate the editing session. 

Note that a user may belong to many different groups. By using the newgrp command, 
the user can change his effective group ID to that of another group. A user’s default 
group is specified by his group ID entry in /etc/passwd. 
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Creating and Using a Recovery System 

A recovery system is a bootable subset of your HP-UX system. It contains only enough 
of the system to allow you to boot and to help fix your file system. It is used only if your 
normal HP-UX system cannot boot. 

Once your system has been installed, the first thing you should do is make a recovery 
system. Then, if you can’t boot from your root disk because your root disk is too corrupt 
or because you forgot your root password, your recovery system will be available to boot 
and repair your file system. 

The recovery system is easy to build, and is invaluable if you ever need it. A recovery 
system is built using a shell script, /etc/mkrs. You can build a recovery system in multi¬ 
user mode; you don’t need to have your users log off You will build your recovery system 
on one 150-foot cartridge tape. 

When to Create/Recreate the Recovery System 

You should create a recovery system as soon as you have installed your HP-UX operating 
system and configured/customized it. 

Each time you change the boot area or configuration (such as changing the console device) 
on your root system you should also remake your recovery system. This is required if 
changes to the console device resulted in a change to /dev/console. In other situations 
(such as changing the boot area) it will save you time if you ever need to re-create a root 
system—if your recovery system is up-to-date, then you don’t need to remember what 
was in your root system to get it back to the same run-level. 

Note that you may not know if your boot area has been altered: this may be done 
automatically during an update. To check this, use the osck -v command for both the 
root system and the recovery system. If the two boot areas are different, then you should 
remake the recovery system. 
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Creating a Recovery System 

Four programs are needed to make a recovery system: 

• /etc/mkrs— a shell script that creates the recovery file system 

• /etc/dolinus — a program that sets several file system parameters to values that 
are optimal for cartridge tape (called by mkrs) 

• /etc/undolinus — a program that resets the file system parameters to their usual 
values (called by mkrs) 

• /etc/mkrs .devs — a program that finds the major and minor number of your root 
device 

The recovery system has a boot area so you can boot using just the recovery system. The 
recovery system also has a small file system, containing the following files and directories: 


/bin The /bin directory contains a small subset of HP-UX commands. Use the is 
command to list the files you have on your recovery system. 

/dev The /dev directory contains the device files that existed on your system when 
the recovery system was created. 

/disc This directory can be used to mount a file system. 

/etc The etc directory contains the tools and files necessary to fix your root file sys¬ 
tem: fsck, init, mknod, oscp, osck, rootmark, sdfinit, mount, and umount. 
It also contains small inittab, profile, and rc files, which are necessary for 
booting. 

/tmp This directory is used for temporary file storage. 
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To create the recovery system: 

1. Log in as the super-user, root. 

You will be accessing privileged commands, so you must have super-user privileges. 

2. Determine whether the device files in /dev exist for the tape drive on which you wish 
to create the recovery system. The mkrs program will use the following defaults: 

a. Default for the root device: /dev/dsk/OsO, /dev/root, or /dev/hd. One of these 
files should exist on your system. If none of them exist, you must either create 
one of them or supply the name of the device file associated with your root 
disk as an option on the command line. The root device file can be either 
block or character type; the other does not have to exist. 

b. Default for the recovery device: /dev/update. src, /dev/rct/cO, or /dev/rct. 
One of these files should exist on your system. If none of them exist you must 
either create one of them or supply the name of the device file associated with 
the recovery device as an option on the command line. The recovery device 
file can be either block or character type; the other does not have to exist. 

Refer to the section “Adding Peripheral Devices” for procedures on how to create 
device files. 

3. Create the recovery system by using the mkrs command, mkrs has the form: 

mkrs [-f rcdev^ [-r rootdev] [-t type] [-v] [-m series] 

See the following section, “Using the mkrs Script”, for details on options and de¬ 
faults. 

4. Boot the recovery system to verify that it works. For this step, you will need to 
shut down the system. You probably will want to test-boot the recovery system 
during off hours if you have other users on your system. Follow the steps in the 
section “Booting the Recovery System”. 

5. Put the recovery system in a safe place and LOCK IT! 

When you boot using the recovery system, you come up as the root user. This is 
potentially a serious security problem. It is up to you, the system administrator, 
to keep this recovery system safe (so you can use it if needed) and out of sight (so 
unauthorized people do not have access to it). 
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Using the mkrs Script 

mkrs has the form: 


mkrs [ 
where: 
rcdev 


rootdev 


type 

series 


f rcdev] [-r rootdev] [-t type] [-v] [-m series] 


is the name of the device file for the recovery system (i.e., the cartridge 
tape drive or flexible disk drive you are creating the recovery system on). 
The mkrs command will, by default, look for the following device files: 

/dev/update.src if it exists as a character device file, else 

/dev/rct/cO if it exists as a character device file, else 

/dev/rct if it exists as a character device file, else 

the device file must be specified. 

If none of the above defaults exist on your system, you must either create 
one of them or you must specify the recovery device file using the -f option. 
The recovery device file can be either a block or a character device file. 

An error message will result if the user does not use one of the defaults 
and does not specify a recovery device file name. 

is the name of the device file for the root device. The mkrs command will, 
by default, look for the following root device files: 

/dev/dsk/OsO if it exists as a block device file, else 

/dev/root if it exists as a block device file, else 

/dev/hd if it exists as a block device file, else 

the device file must be specified. 

If none of the above defaults exist on your system, you must either create 
one of them or you must specify the root device file using the -r option. 
The recovery device file can be either a block or a character device file. An 
error message will result if a default root device file does not exist and the 
user does not specify a root device file name. 

can be either ct (cartridge tape) or md (micro disk). The default is ct. This 
is correct for your S500 system. 

This value is normally not needed. If mkrs cannot determine the type of 
system you have it will send you an error message. If this happens re- 
execute mkrs using the -m option with either 300 or 500. Since you are 
creating the recovery system for your Series 500 machine, use the value 
500. 
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For example, if your root file system is associated with the device file, /dev/dsk/OsO, and 
you will be creating your recovery system on the tape drive associated with the device 
file /dev/rct2, you would type the following command: 

mkrs -f /dev/rct2 

The mkrs process takes about 1 hour on a 150-foot cartridge tape. 

Booting the Recovery System 

To use your recovery system you will need to boot, then use the recovery tools to gain 
access to your root disk. Follow these steps to boot your system: 

1. Power up the tape drive that will hold your recovery tape. Put the recovery tape 
in the tape drive and wait for the busy light to remain off. 

2. Turn on your computer. The boot ROM will search your on-line disk and tape 
drives for the first bootable operating system. You must make sure the tape drive 
containing the recovery systaem is the first device the boot ROM finds. Unless you 
have an HP 7935 hard disk on line, or have another cartridge tape drive on line, 
the recovery system will probably be the first bootable system. Refer to Chapter 
4: “System Startup and Shutdown”, the section called “The Boot ROM’s Search 
Sequence” for more details. 

The booting process takes about 10 minutes. When it’s done, you will see the 
words: 

Welcome to the HPUX Recovery System 
You are now in the recovery system. 
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Shutting Down the Recovery System 

Following is the correct method of halting, or shutting down, your recovery system: 

1. Make sure the hard disk (root disk) is not mounted. To check, execute the mount 
command with no parameters. If the disk is mounted, unmount it by entering: 
amount /dev/hd 

2. Execute the sync command. 

3. When the busy light on the tape drive remains off, halt the system by entering: 

reboot -h 

4. Turn off power to the computer. 

5. Take the cartridge tape out of the disk drive. 

6. Turn on power to the computer and boot from the hard disk (root disk). 

Using the Recovery System 

A recovery system is intended to repair certain damage that might occur on your root 
file system. However, if the damage is severe or if the damage extends across the entire 
file system, it may be easier to re*install HP-UX and then restore files from your backup 
media. 

This section describes how to recover from specific, and often localized, problems on your 
file system. If none of these problems apply to your situation, or if after correcting these 
problems you still cannot boot from your root disk, then you probably need to re-install 
the system and restore from backups. 

Once you have booted your recovery system and you see the shell prompt on your display, 
you can use the following steps to try to recover your root file system. The procedure 
outlined here makes the following assumptions: 

• you cannot boot your regular system; you suspected a problem and used the recov¬ 
ery system to boot 

• your root device is called /dev/hd (block device file) and /dev/rhd (character device 
file) 

• your recovery device is called /dev/ct (block device file) and /dev/rct (character 
device file) 
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Use 11 “R /dev to determine what device files are actually present on the recovery system. 


Root device, in the following procedure, refers to the device that is root under normal 
circumstances (the hard disk drive associated with your root file system). 

Step 1. Check Your File System 

If you think your root file system is corrupted, then run f sck on the character device file 
associated with your root device (for example, /dev/rhd). 

If the fsck appears to solve the problem, then shut down the recovery system and reboot 
from your hard disk. Shutdown procedures are described in the section “Shutting Down 
the Recovery System”. 

If the reboot fails, then come up on the recovery system again and go on with step 2. If 
the boot succeeds but other problems still exist on the disk (such as missing or corrupted 
files), then go to Step 4. 

Step 2. Mount the Root Device 

Once the integrity of the file system is ensured, mount the root device using: 
mount /dev/hd /disc 


Step 3. Check the Critical System Files 

To get your root volume to a state where you can boot from it, you need to check several 
files. The critical files for HP-UX are listed below. You should still be booted from the 
recovery system. For each file, the appropriate action to fix the file is also listed: 

File Action 

/bin/sh Copy the version of this file on the recovery system to the root vol¬ 

ume, then remove and relink /bin/rsh. The commands are: 

cp /bin/sh /disc/bin/sh 
In /disc/bin/sh /disc/bin/rsh 

/etc/init Copy the version of this file on the recovery system to the root vol¬ 

ume: 

cp /etc/init /disc/etc/init 
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/etc/inittab 


etc/ioctl.syscon 


/dev/console 


If inittab is corrupted, init might fail. To work around this problem, 
save the inittab file (you may want to go edit it later), then create 
a single line inittab. Do this as follows: 

mv /disc/etc/inittab /disc/etc/inittab.save 
echo "is:s:initdefault:" > /disc/etc/inittab 

Be very careful to type the second line exactly as shown (including 
the quotes). 

If you have changed the device used as the console, it is possible 
that /etc/ioctl. syscon is incorrect, or it may have otherwise become 
corrupted. Work around this problem by removing the file (the next 
time the system is booted a correct file will automatically be created): 

rm /disc/etc/ioctl.syscon 


This file (which is also linked to /dev/syscon and /dev/systty) could 
be corrupted. If it is corrupted, or if the file does not match the 
console, then the system may not boot. 

If you have not made changes to the console device on your root 
volume then use the following information to compare these files on 
the recovery system to the files on the root volume. Type: 

11 /dev /disc/dev 

If the files on the root volume do not match those on the recovery 
system, then correct the problem by doing the following: 

# remove the three files, console, syscon. and systty 
rm /disc/dev/console /disc/dev/syscon /disc/dev/systty 

# Use the appropriate parameters to make /dev/console match 

# the /dev/console file on the recovery media (using 
mknod). 

# Note that you cannot copy (using cp) device files. 

# link the files 

In /disc/dev/console /disc/dev/syscon 
In /disc/dev/console /disc/dev/systty 

If you have changed the console device refer to the section called 
“Notes on the System Console Device” at the end of these proce¬ 
dures. 
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Step 4. Fix Other Problems 

If you have rebooted from the root volume, you can now fix other possible problems as 
described below: 

1. If /etc/inittab was corrupted, you can now edit the version that was saved to fix 
it. Once edited, move it back to /etc/inittab. (Refer to the next section for details 
on fixing corrupted files.) Until you have tested your newly edited inittab, you 
should make the default state run-level s. You can switch to other states using init 
X, where x equals the desired run-level, 0-6. 

2. If you lost other system files, you should update your system, update requires that 
at least the following commands be available. 

/bin/sh /bin/mkdir 

/bin/pwd /bin/cpio 

/usr/bin/lifcp /usr/bin/tcio 

/etc/update /etc/sysrm 

If any of these are missing, you can get them from your recovery tape by mounting 
the tape and copying the missing command(s) to the root device. You may already 
have /bin/sh on your system (from Step 3). To get the files onto your system, 
execute the following sequence: 

mkdir /disc only if /disc does not already exist 

mount /dev/ct /disc 

cp /disc/bin/mkdir /disc/bin/pwd /disc/bin/cpio /bin 
cp /disc/usr/bin/lifcp /disc/usr/bin/tcio /usr/bin 
cp /etc/update /etc/sysrm /etc 

3. If you think the boot area on your root device has been corrupted, then create a 
raw device file for root (assuming none exists) and copy the boot area from the 
recovery system to the root device as follows: 

oscp -o /dev/rct /dev/rhd 


NOTE 

The boot area on the recovery system is a copy of the boot area that 
existed on the root disk when the recovery system was created. 
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Also, the commands normally used to create backups are on your recovery tape. 
These commands are cpio, tcio, and tar. If these commands are missing from your 
root disk, and you wish to restore from backups, you can mount the recovery tape 
and copy the commands to the root disk. Refer to the procedure in Step 4 for 
copying commands from the recovery system to the root disk. 

Notes on the System Console Device 

When you change the console device you may also need to make changes to the boot area 
and/or to the device file (/dev/console). The following changes to the system console 
device require changes to either the boot area or to the /dev/console file: 

• changing the console from a terminal connected to an ASI or 8-port mux card to 
a terminal connected to a 6-port modem mux card changes the major number of 
/dev/console from 31 to 29, changes the minor number (see “Consoles” in the sec¬ 
tion “Adding/Moving Peripherals”), and requires the optional HP27140.opt driver 
segment in the boot area (the ASI and 8-port mux cards use the optional driver 
segment HP27128.opt), 

• changing the console from a terminal connected to an ASI or 8-port mux to an 
HP 98700 display changes the major number of /dev/console from 31 to 29, changes 
the minor number (see “Consoles” in the section “Adding/Moving Peripherals”), 
and requires the optional HP98700.opt driver segment in the boot area (the ASI 
and 8-port mux cards use the optional driver segment HP27128.opt), 

• changing the console from a terminal connected to a 6-port modem mux card to an 
HP 98700 display does not change the major number, but does change the minor 
number of /dev/console (see “Consoles” in the section “Adding/Moving Peripher¬ 
als”), and requires the optional HP98700.opt driver segment in the boot area, 

• the reverse of the above three scenarios. 


The System Administrator’s Toolbox 203 



If you have changed the console device AND your system is not bootable then one of the 

following probably happened: 

• /dev/console was not changed as required to match the new console device. You 
cannot use the recovery system to fix this (you won’t be able to boot from the 
recovery system). You need to boot from the regular system and put the old console 
device back on the system, boot, make the appropriate changes to /dev/console 
(remove the existing /dev/console, syscon, and systty). If the required driver 
segment is not in the boot area, then add it (use oscp as shown below to add the 
segment to the boot area), shutdown your system, put the new device back on, and 
reboot. 

oscp -a /disc/system/<hpux_product_#>/<segment> /dev/rhd 
osck -V /dev/rhd 

where <hpux_product_#> is the product number of the HP-UX operating system 
(the product number will be on the label of your most recent installation or update 
tape) and <segment> is the name of the optional driver segment that is needed 
(identified above). 

• /dev/console was changed INCORRECTLY. You must boot from the recovery sys¬ 
tem using the old console device. 

Once booted you can fix this by doing the following: 

rm /disc/dev/console 
mknod /disc/dev/console c major minor 
rm /disc/dev/syscon disc/dev/systty 
In /disc/dev/console /disc/dev/syscon 
In /disc/dev/console /disc/dev/systty 

where major is the appropriate major number and minor is the appropriate minor 
number. 

• /dev/console was changed correctly but the kernel segment required to use the new 
device is not present in the boot area. You must boot from the recovery system 
using the old console device. 

Once booted you can fix by doing the following: 

oscp -a /disc/system/<hpux_product_#>/<segment> /dev/rhd 
osck -V /dev/rhd 

where <hpux_product_#> is the product number of the HP-UX operating system 
(the product number will be on the label of your most recent installation or update 
tape) and <segment> is the name of the optional driver segment that is needed. 
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Media Utilities 

Media is what you store data on: hard disk, flexible disk, cartridge tape, or 9-track tape. 
This section discusses the commands and utilities you should use to initialize, monitor, 
maintain, and use with your media. 

The following concepts are covered: 

• Initializing media 

• Initializing hard disks for IIP-UX use 

• Initializing LIF volumes 

• Commands and utilities to store files and transfer files between computers 

• Commands to monitor your file system 

• Commands to verify the integrity of your media 

Initializing Media 

What Is Initialization? 

Before a disk or tape can be used for the first time, it must be initialized (or formatted) 
for use with your disk drive and computer. Initialization performs two main functions: 

• Checks the mass storage media for defects (areas where information cannot be 
stored). 

• Sets up a directory (a list of the files on the disk or tape). 

When Do You Need to Initialize? 

You need to initialize: 

• media you use as part of your HP-UX file system (sdf init) 

• media you wish to use to transfer files between HP-UX and a language workstation 
(lifinit) 

• flexible disks (always before you use them the first time) (sdf init) 

You do not need to initialize: 

• cartridge tape and 9-track tape that you wish to use to transfer files between two 
HP-UX or UNIX systems using tar, tcio, cpio. 

Initialization of the HP-UX root disk is performed as you are installing the HP-UX 
system on your computer. If this is the only mass storage device you will be using, then 
you need not be concerned with any further initialization. 
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initializing Disks to SDF Format 

The Series 500 computers recognize SDF (Structured Directory Format) on initialized 
disks and tape. The sdfinit command is used to initialize media in this format. 

The sdfinit command performs five functions: initialization, certification, interleave 
factor selection, block size assignment, and boot area creation. 

Initialization 

It initializes your media in SDF, which is recognized by all HP 9000 Series 500 computers. 

Certification 

It optionally certifies your media. Certification verifies that the media accurately repro¬ 
duces the data written on it. If any portion of the media fails certification, that portion 
is “spared” - that is, excluded from any further I/O operations. 

The certification process can be disabled by specifying the -i option on the sdfinit 
command line. Note that use of the -i option is strongly discouraged. Although skipping 
the certification step saves time, you are left with initialized media whose reliability is 
unsure at best. 

Interleave Factor 

It selects an interleave factor for the media. The interleave factor is an integer specifying 
how many (if any) sectors are skipped each time an I/O operation occurs (a sector is the 
smallest amount of media space that can be read or written at one time). 

For example, an interleave factor of two (2) causes sectors 1, 3, 5, 7, ... to be written on 
or read from. When the end of the track is reached, the media wraps around and begins 
using sectors 2, 4, 6, and so on. Thus, two passes are required to fill the media. If an 
interleave factor of four (4) is specified, the media uses sectors 1, 5, 9, 13, ... on the first 
pass, sectors 2, 6, 10, 14, ... on the second pass, sectors 3, 7, 11, 15, ... on the third 
pass, and finally sectors 4, 8, 12, 16, ... on the final pass. 

The purpose of the interleave factor is to facilitate maximum data transfer to/from the 
media. Faster devices (such as hard disks) do well with an interleave factor of one (i.e. 
no sectors are skipped). This puts data closer together on the media, enabling data to 
be provided s fast as the device can read it. Slower devices (such as external flexible 
disk drives) need a larger interleave factor to provide data slowly enough for the device 
to process it. 
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In general, SS/80 disks work best with an interleave of 2, CS/80 disks work best with an 
interleave of 1. 

If no interleave factor is specified, sdf init assigns a default of one. This works well with 
most media. The exceptions are the internal 10 megabyte Winchester disk available on 
the Model 520, which has a recommended interleave factor of four, and external flexible 
disk drives. Note that the built-in flexible disk drive on the Model 520 has been optimized 
such that an interleave factor of one is appropriate. 

Block Size 

It assigns a block size to be used in data transfers to/from the media. A block size is an 
integer specifying the number of bytes per block of data. When data is then written to 
or read from the media, it is saved up until one block’s worth of data is accumulated, 
and then the entire block is transferred. 

The block size is used to simultaneously determine the amount of media space used, and 
the speed at which data transfers are made. Smaller block sizes save media space but 
cause inefficient data transfers. Larger block sizes cause data to be transferred more 
efficiently and quickly but waste media space. 

To illustrate the block size’s effect on media space, you need to understand how a block 
size is used by a particular medium. Whenever a block size is defined, the medium for 
which it is defined automatically allocates one block for every file yet to be created on 
that medium. Thus, if the block size is 2048 bytes, for example, a file containing 32 
bytes is still allocated 2048 bytes, leaving 2016 bytes that are unused yet unavailable for 
any other use. If the file happens to grow such that it now contains 2049 bytes, another 
2048-byte block is allocated for it, leaving 2047 bytes unused and therefore wasted. When 
a medium becomes riddled with these chunks of unused space, it is said to be internally 
fragmented. 

Large block sizes, however, permit much more efficient data transfer. For example, 
consider the two block sizes, 256 bytes and 2048 bytes, which are to be used to read a 
1 megabyte file. If the medium on which the file resides was initialized with a 256-byte 
block size, it would take 3907 read operations from the medium before the entire file 
is read. With the 2048-byte block size, however, only 489 read operations are needed. 
You can see the larger block size greatly reduces the number of device accesses needed, 
thereby reducing wear and tear on the device. Also, the data can be transferred in much 
less time. 
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Obviously, a compromise must be made. The recommended block size for hard disks is 
1024 bytes. For flexible disks, block sizes of 256 bytes or 512 bytes work well. Depending 
on the application, block sizes should not exceed 4096 bytes (sometimes useful for serial 
data access from hard disks). If the block size you specify is not a power of two, sdfinit 
rounds it up to the next power of two. If you do not specify a block size, sdfinit uses a 
default block size of 512 bytes. 

One final point to keep in mind involves the cache buffer size (set by the uconfig(lM) 
command) and its relationship to the block size. You should never set the cache buffer 
size smaller than the largest block size you are supporting on your system. For example, 
if you have a hard disk with a block size of 2048 bytes, a hard disk with a block size of 
1024 bytes, and two flexible disk drives with block sizes of 256 and 512 bytes, respectively, 
your cache buffer size should be at least 2048 bytes. If in this example the cache buffer 
size is 1024 bytes, the number of cache buffers would effectively be halved, degrading 
system performance. If the cache buffer size is 4096 bytes, half of every cache buffer 
would be wasted. 

Boot Area 

It optionally creates a boot area on the medium being initialized. A boot area is a section 
of the volume which is set apart to contain the various code segments needed to boot 
up HP-UX and any optional products you may have purchased. If you want to use a 
particular medium as the boot-up device for your system, then specify the boot area size, 
in bytes, on the sdfinit command line. A minimum boot area size of 500000 bytes is 
recommended. If you omit the boot area size, sdfinit uses a default size of zero bytes 
(no boot area is created). 

Using sdfinit 

When is it appropriate to use sdfinit, and on what devices? You should always use 
sdfinit on hard disks. Do not use sdfinit on nine-track magnetic tape. 

For pre-certified cartridge tapes, do not use sdfinit if you are using the cartridge tape 
with backup, tcio, or other raw applications (i.e., those applications using character 
special files). If you want a boot area on the pre-certified cartridge tape, you should use 
sdfinit (with the -i option to inhibit certification). 

For cartridge tapes that have not been pre-certified, sdfinit should be used to certify 
them (i.e., do not use the -i option). 
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A helpful hint: if you have any medium that you would like to certify, but you do not 
want the Structured Directory Format written on the medium, specify a bootsize which 
is larger that the total capacity of the medium. For example, for a DC500 cartridge 
tape, specify a bootsize greater that 67 megabytes. Sdfinit completes the certification 
process, and then aborts when it determines that the specified bootsize is too large for 
the medium. 

Examples 

sdfinit /dev/hd 1024 1000000 

This example initializes the hard disk addressed by /dev/hd with a block size of 1024 
bytes, and a boot area of 1 Mbyte. The default interleave factor of one is selected. 

sdfinit /dev/rfd.O 256 0 3 

This example initializes the flexible disk addressed by /dev/rfd.o with a block size of 
256 bytes, a boot area size of zero, and an interleave factor of three, 

sdfinit /dev/ct881401 512 100000000 

This example certifies the DC600 cartridge tape addressed by /dev/ct8814011. Sdfinit 
aborts after certification because the specified boot area size (100 Mbytes) is larger than 
the capacity of the cartridge tape. 


Initializing Media to LIF Format 

Note that if you are going to make a LIF^^ copy of files on a flexible disk you can use 
the LIF commands covered in the HP-UX Reference. These commands allow you to 
make copies of LIF ASCII files on media initialized using any HP Series 200, 300 or 500 
workstation-based operating system, whether it be Pascal or BASIC. 


LIF stands for Logical Interchange Format. It is an HP standard format used for directories and files 
on mass storage devices (such as flexible and hard disks). It allows media interchange between various 
machines that use it, such as using the same disks with several 5V4 and 3V2 inch flexible disk drives 
made by HP. 
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Is the Media Initialized? 

To determine whether or not your disk is initialized in LIF format: 

• place it in your disk drive, 

• type the following: 

lifls /dev/rfdO 

where lifls is the command to list the files on the flexible disk, and /dev/rfdO is 
an example of a special device file name. 

The above steps causes a list of files similar to the following to be displayed if the disk 
has been initialized and contains files. 

PLOT.DEMO PRINT.DEMO GINPUT.DEMO HELLO.DEMO HELLO.TEST 

If the disk is not initialized the following appears in your display: 

lifls(open): I/O error 

lifls : Can not list /dev/rfdO; NOTLIF 


Creating a LIF Volume 

You can create a LIF volume in the HP-UX file system with the lifinit command. If your 
media has never been initialized, it must be initialized using sdfinit before lifinit can be 
used. Lifinit writes a LIF volume header on a volume or file and has the following form: 

lifinit [-vnnn] [-dnnn] [-n VOL_NAME\ FILE_NAME 
The options may appear in any order. Definitions of the options are: 


-vnnn sets the volume size to nnn bytes. If nnn is not a multiple of 256, 

it is rounded down to the next such multiple. This number should 
be the capacity of the media you wish to copy files to (for example, 
270336 for 5 V 4 inch flexible disks). If you do not specify a volume 
size it will default to 256 Kbytes for regular files. 

-dnnn sets the directory size to nnn file entries. If nnn is not a multiple 

of 8, it is rounded up to the next multiple. If you do not specify a 
directory size the default size is calculated based on the volume size. 
Refer to the lifinit(l) entry in the HP-UX Reference for details. 
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-n VOL_NAME sets the volume name to be VOL^NAME. If the -n option is omitted, 
the volume name is set to the last component of the path name 
specified by FILE NAME. If VOL_NAME\s longer than 6 characters, 
it is truncated to 6 characters. VOL_NAME must be all uppercase 
(this is a LIF standard). 

FILE_NAME The name of the file on the LIF volume. F1LE_NAME must be all 
uppercase (this is a LIF standard). 

For example, to write a LIF volume header to an HP-UX file that is to be copied to a 
flexible disk, type the following: 

lifinit -V270336 -d240 -nVOL VOL 

where the volume size is the total number of bytes contained on a 5 V 4 inch flexible disk. 
Note again that the LIF standard dictates that both the LIF volume name (-nVOL) and 
the LIF file name must be in uppercase. 

Although LIF volume files can exist without problems on HP-UX, the system sees them 
as being possible bad files and so it generates a warning about them during executions 
of fsck (file system check). For this reason, you should remove LIF volume files when 
you are through with them (after their contents have been stored on flexible disks). 

Commands and Utilities to Transfer Files 

The commands you can use to transfer files are: 

• cpio 

• ftio 

• tcio 

• tar 

• dd 

• LIF Utilities 

Each of these commands and utilities is described below. 
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cpio 

This command is used to transfer files between your hard disk, 9-track magnetic tape, 
and flexible disks. It is also used with tcio to transfer files to/from cartridge tape. 

It accepts a list of files from standard input (i.e., through pipes or redirection) and 
generates an archive to standard output (i.e., through pipes or redirection). 

Examples of this command are given in the section '‘Backing Up and Restoring your File 
System” in this chapter, and in the HP-UX Reference, cpio(l), 

ftio 

This command has been developed by Hewlett-Packard as a faster alternative to cpio or 
tar. It is similar to cpio and can be used for the same purpose. It is also compatible 
with cpio in that output from cpio is always readable by ftio and output from ftio is 
readable (with exceptions) by cpio. Refer to the ftio(l) entry in the HP-UX Reference 
for more information. 

tcio 

The command, tcio, is used primarily as a filter between archiving programs and a 
cartridge tape. The two main archiving programs on HP-UX are tar and cpio). tcio en¬ 
ables immediate report (which enables streaming) for cartridge tape drives that support 
immediate report (9144 drives). It also allows buffering of data into large blocks (up to 
64 Kbytes) -this reduces wear and tear on older devices that don’t support streaming. 

Additionally, tcio provides utility functions (-u option) such as unloading tapes, writing 
tape marks at specific blocks (by default, it writes a tape mark to block 0 to prevent 
accidental image restores), and performing software-driven verification. It also provides 
the user a software interface to autochanger units, allowing the user to specify which of 
a set of tapes to read, write, or load. 

Examples of this command are given in the section “Backing Up and Restoring your File 
System” in this chapter, and in the HP-UX Reference, tcio(l). 

tar 

tar should be used to transfer files between HP-UX and other UNIX operating systems 
since tar is standard on all UNIX systems. The tar command (tape archive), like cpio, 
understands and keeps intact the hierarchical directory structure. 
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For example, to archive all your users’ directories onto a 9-track magnetic tape at 
/dev/mt/Omn, you would use the following command line: 

tar cvf /dev/mt/Omn -C /users 

This creates (c option) a new archive in the file (f option) /dev/mt/Omn, with the verbose 
(v option). The input for the archive (-C option) is the full /users directory. 

To get the information off the tape into the current directory, enter: 
tar xvf /dev/mt/Omn 


dd 

The command, dd, can be used to copy a file from one place to another. It is different 
from cp in that it can be used to make some conversions on the file, transfer the file 
between different media, or reblock the file. 

One example of how to use dd is when you need to create a new boot area. Since you 
don’t want to write to your boot area until you are fairly sure you have a workable kernel, 
you can copy the first 1024 bytes of your boot area to a file by using dd: 

dd if=/dev/rhd of=temp_file bs=1024 count=l 

then add to and delete from the temporary file (using oscp on the temporary file) until 
you have the boot area desired. Once you have a finished version, use osck to list the 
segments, and recreate the “real” boot area using oscp. 

For more information on the boot area, read the section in this chapter called “Modifying 
the Boot Area”. 

Another example of using dd is when you need to do an image copy from one hard disk 
to another. When doing an image copy, make sure you have properly initialized the 
destination disk so no information is written onto bad tracks. 

LIF Utilities 

The LIF utilities are commands that enable you to read and write files in Hewlett- 
Packard’s LIF format. LIF is a format that HP-UX, the BASIC operating system, and 
the Pascal Workstation all understand (as well as many other Hewlett-Packard operating 
systems). 
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Getting a set of HP-UX files into a format that is readable by a language workstation 
requires three HP-UX commands: lifinit, lifcp, and cat. These commands are used 
in the following three steps: 

1. Create a LIF volume with lifinit (explained in the section called “Initializing 
Media in LIF Format’'). 

2. Use lifcp to write the files to this volume. 

3. Use cat to write the LIF volume to the initialized LIF media (usually a 5 V 4 inch 
flexible disk. 

Copying HP-UX Files to LIF Volumes 

Once you have created a LIF volume, you can write files to the volume using the lifcp 
command. The lifcp command has the following format: 

lifcp hpuxjile VOL_NAME:FILE_NAME 

where hpux_file is a file in your HP-UX directory, VOL_NAME is the name you gave to 
the LIF volume when you created it, and FILE_NAME is the name that file is given on 
the LIF volume. Again, LIF files must be in the uppercase characters. 

For example, if you wish to transfer the HP-UX file called testing.p in the 
/users/engel/progs directory, to the LIF volume called VOLl in the current directory, 
you would use the following command line: 

lifcp /users/engel/progs/testing.p VOLl:TESTING 

You will receive an error message if there is not enough room left on the LIF volume for 
the entire file. You must then create another LIF volume and copy the file to it. 

Moving the LIF Volume to A Disk 

After you have copied your files to the LIF volume file, use the HP-UX cat command to 
write the LIF volume to the flexible disk. Do this with the following steps: 

1. Insert the flexible disk into the disk drive. 

2. List the contents of the disk by executing the following command: 

lifls /dev/file_name 

where fUe_name is the name of the device file associated with the disk drive holding 
your flexible disk (for example, /dev/rfd). 

Listing the the contents of the disk helps determine if there are any files that should 
be saved. If you need to save a file which is on the disk read ahead to the section 
called “Moving LIF Files Onto HP-UX”. 
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3. Copy the LIF volume file to the disk using HP-UX cat. Using the cat command 
to copy files to a flexible disk overwrites everything on the disk. If you think you 
need to save any files on the flexible disk, go back to step 2. 

If your LIF volume name on HP-UX is called VOLl and the flexible disk you wish to 
copy it to is associated with the device file /dev/rfd, you would enter the following 
command: 

cat VOLl > /dev/rfd 

Once the LIF volume has been copied to the flexible disk, remove the LIF volume from 
your current directory by using the HP-UX rm (remove) command. Type the following: 

rm VOLl 

Adding Files to a LIF Volume 

Assume that you already have a 5 V 4 inch flexible disk in LIF ASCII format and you now 
want to write an additional file to the disk leaving the current contents of the disk intact. 
To do this, you use the following command: 

lifcp hpuxjile /dev/file_name:FILE_NAME 

where hpux_file is the HP-UX file you want to copy to the LIF disk; file_name is the 
name of the device file associated with the flexible disk drive (for example rfd); and 
FILE_NAME is the uppercase file name given to the hpux_file stored on your LIF disk. 

Before copying a file to the disk, it is a good idea to check to see how much storage space 
you have on the disk. To find out how much space there is left on your flexible disk, 
type: 

lifls -1 /dev/file_name 

This gives you a listing of the files on the disk and how much room they are consuming. 
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Moving LIF Files Onto HP-UX 

There are some occasions where it becomes necessary to copy LIF files from a flexible 
disk to the HP-UX file system. An example of this is if you have just receive the latest 
revision of a program on a flexible disk and need to transfer it to the hard disk on your 
system. To read a LIF file from a flexible disk into your HP-UX directory you must: 

1 . Place the flexible disk in the disk drive. 

2. List the files on the flexible disk using the lifls command as previously stated. 
This helps you to verify that the file is on the disk. 

3. Copy the file FILE_NAME from the disk into the HP-UX file hpux_file using the 
following command line: 

lifcp /dew/dev_file:FILE_NAME hpux_file 

where dev^file is the file name associated with the disk drive holding the LIF file. 

For example, if you wish to copy the file called TESTING from the disk in the 
disk drive associated with the /dev/rfd file, to a file called testing. p, type in the 
following command line: 

lifcp /dev/rfd:TESTING testing.p 

Commands to Monitor Your File System 

Monitoring your file system includes looking for very large files (find), checking for disk 
usage (du), and checking for the amount of free disk space df). These are described in 
the section, '‘Controlling Disk Use”, in this chapter. 

In addition to the commands discussed in “Controlling Disk Use”, you can use HP-UX 
system accounting to monitor system usage. Refer to the chapter “System Accounting”. 

Commands to Verify the Integrity of your Media 

To verify the integrity of the data on your file system, you should use the f sck command. 
For information on fsck refer to the appendix “FSCK”. 

In addition to fsck, a program called fsdb can be used to “de-bug” your file system, fsdb 
must be used with great care, and should be used only by HP-UX gurus. 

The only way to ensure you always have a copy of your files and file system is to do 
periodic backups. Backup concepts and steps on how to perform a backup is covered in 
“Backing up Your File System” in this chapter. 
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Modifying the Boot Area 

There are times when you will want to add or remove code segments (usually drivers) 
from the boot area of your HP 9000 Series 500 computer. When you installed your HP- 
UX system the boot area was configured to match the equipment you had connected 
at that time (and this may not be totally true). For example, there are three different 
console drivers. If you installed HP-UX from an HP 98700 display device connected to a 
6 port modem mux, then you will have the code necessary to support both the HP 98700 
and the mux at driver 29. At some time later, though, if you want to use an HP 2623 
terminal as the console (also on the 6 port modem mux) you will need the code for the 
HP 2623 in the boot area. 

Before modifying your system, you must shut down your system to bring it to run-level 
s. See the “Shutting Down the System” section in Chapter 4 for more information on 
this procedure. Hewlett-Packard recommends that you also do an fsck before altering 
your kernel. 

To add or delete segments from the boot area (kernel), you must be logged in as root 
(the super-user account) and be in run-level s. 

How to Add Segments 

A list of optional kernel segments is given in the section “Optional System Segments”. 

To install an optional segment, type in: 

oscp -a /system/xxxxxxxx/yyyyyyyy /dev/rhd 

where xxxxxxxx is the product number of the code you wish to install, yyyyyyyy is a 
segment which resides under that directory, and /dev/rhd is the boot volume character 
special file. As an example, let’s say you wish to add the Local Area Network segment: 

oscp -a /sy8tem/50954A/localnet.opt /dev/rhd 

Once you have added code to the kernel, you will need to reboot the system. Since the 
kernel is loaded into memory at the time you boot, no change will be reflected until you 
stop and restart the system (or execute reboot -r). Refer to the section “Shutting Down 
Your System” in Chapter 4 for more information. 
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Removing Segments 

There are two basic steps you must follow to safely remove a kernel segment: first split 
out the good section into a file (for example, new.kernel)^ and then replace the old boot 
area with your newly created kernel. To accomplish this first step, type: 

oscp -s /dev/rhd 

where /dev/rhd is the volume containing the boot area. The oscp command is 
interactive—it will prompt you to find out what to do with each kernel code segment: 

SEGMENT OFFSET BYTES SYSTEM/TYPE SEGMENT REVISION 

0 0 4188 HP-UX STANDARD SYSTEM POWERUP 5.1 

File to append segment to? (system) new.kernel 
Appending to file (’new.kernel’) 

You must tell oscp to put the segments you want to keep in the file new.kernel. After 
you specify new.kernel you will be able to hit the I Return | key to get this file as the 
default—until you specify a different file. 

When you get to the segment you wish to remove, respond with a new file name. By 
redirecting the segment to /dev/null you will eliminate that segment (the original should 
still be in the /system directory): 

43 301356 12476 HP-UX STANDARD INTERNAL HP-IB 5.1 

File to append segment to? (’new.kernel’) /dev/null 
Appending to file (’/dev/null’) 

After rerouting the undesired segment to /dev/null if you get another segment you wish 
to keep, you must enter new.kernel once again. In general, make sure that you route all 
the segments you want to keep into the new.kernel file. 

You may wish to remove driver segments to decrease the size of the boot area. This 
is desirable, since the kernel always remains in memory. For example, if you had the 
segment for Local Area Net in your current boot area, and you do not use LAN, you are 
wasting in excess of 300 Kbytes of memory. 

To actually update the operating system in the boot area, you simply enter: 
oscp -m new.kernel /dev/rhd 

oscp: please enter new system ID (non-blank ID required): 

NEW AND IMPROVED 


218 The System Administrator’s Toolbox 



This overwrites the boot area on /dev/rhd with the file you just created, new.kernel. 
Notice that oscp asked for a new ID field to label the new boot area with. We chose 
NEW AND IMPROVED for this example, but you will probably want something a little more 
descriptive. 

Once you have overwritten code to the kernel, you will need to reboot the system. Since 
the kernel is loaded into memory at the time you boot, no change will be reflected until 
you stop and restart the system (or execute reboot -r). 

Replacing Segments 

If you need to replace a segment with a newer version, you need to remove the old segment 
(refer to the section “Removing Segments”), and then add the new segment (refer to the 
section “How to Add Segments”). 

Checking the Boot Area 

HP-UX has a command to list what is in your boot area- osck. You may execute osck 
at any time; the system need not be shut down (in run-level s): 

osck -V /dev/rhd 

For more information on the boot area, see Chapters 3 and 4 of this manual, and the 
oscp(lM) entry in the HP-UX Reference. 

Optional System Segments 

A segment is a piece of code that can be added to your kernel to allow you to use 
additional devices or products. Some segments are required, and will always be included 
in your kernel. The segments in Table 5-19 are optional segments, and are stored under 
a /system/xxxxxxx directory, where xxxxxxx is the product number you have purchased. 
For example, /system/97083A is the multiuser IMAGE directory, and /system/97089C 
is the 16-user 550 directory. Table 5-19 includes the driver number (used in the mknod 
command), the segment name, and a description. 
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Table 5-19. Optional System Segments 


Driver 

Number 

Segment 

Name 

Description 

14 

CIPERLRopt 

Ciper printers; e.g., HP 2608 

35 

HP268X.opt 

HP 2680 and HP 2688 laser printers (not HP 2686) 

18 

HP27112.opt 

HP 27112A GP-IO (general purpose I/O) card 

38,39 

HP27125A.opt 

LAN interface card (HP 27125 Ethernet and IEEE 802) 

31 

HP27128.opt 

Normal transfer to ASI and 8-port MUX cards (HP 271128 
and HP 27130) (see driver #19) 

29 

HP27140.opt 

6-port modem MUX card. This segment is required on 
the Model 520, or if your console is on the MUX card, or 
if you console is the HP 98700. 

11 

HP7970.opt 

HP 7970 and HP 7971 9-track magnetic tape drives 

36 

HP7974.opt 

HP 7974 and HP 7978 9-track magnetic tape drives 

32 

HP97062_GR.opt 

Graphics for the standard console display on the Model 
520 and HP 97062 color output interface 

29,41-43 

HP98700.opt 

Bit-mapped displays and ITE 

28 

HP98770_GR.opt 

Monochromatic and high performance color displays on 
the Model 520 (used by Device independent Graphics Li¬ 
brary) 

9 

HP9885.opt 

HP 9885 8-inch flexible disk drive 

6,8 

HPIB.FLEX.opt 

HP 9895 5V4-inch flexible disk drive, HP 8290X 5 V 4 -inch 
flexible disk drive (not built-in) 

none 

im*opt 

Image Data Base 

none 

fcs*opt 

Image data base utilities 

10 

MEMORY. VOL.opt 

Accessing memory as a pseudo-mass storage device (refer 
to sdfinit(l)) 

34, 40 

localnet.opt 

Basic local area network capabilities (HP 2285 Ethernet 
and IEEE 802) 

19 

SERIAL.opt 

Raw transfer to ASI or 8-port MUX interface cards (see 
driver #31) 

33 

SRM.opt 

Shared Resource Manager interface 

none 

debug*opt 

System debugger 
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Mounting and Unmounting File Systems 

When HP-UX is installed, only one file system (the root file system) exists. You may 
create, modify, and delete files from this system. By default (i.e., installation), the HP- 
UX file system exists on this one volume and therefore, on one CS/80 or SS/80 mass 
storage medium. It is possible to have other file systems on different file systems; any 
other mass storage device supported by Series 500 HP-UX can be used as an additional 
file system. To accomplish this, the additional file system(s) are attached to either the 
directory (root) or other mounted file systems. The process of attaching additional 
and functionally independent file systems to the root file system is called mounting and 
is achieved with the moiint command. The process of removing independent file systems 
from the root file system is called unmounting and is achieved with the umount command 
(note that the spelling is umount, not unmount). 

Once a block special (device) file exists for the new disk device (and the disk is ini¬ 
tialized, of course), the file system the device contains can be mounted. See the 
“Adding/Removing Peripheral Devices” section in this chapter for information on cre¬ 
ating device files. The mounting operation makes any files on the new (mounted) file 
system become part of the file system hierarchy. Files can then be created, modified and 
deleted on this new file system. When you are finished with the files on that file system, 
it can be unmounted. Unmounting a file system removes its files from the file system 
hierarchy. More specifically, the association between the mounted file system and the 
root file system is broken (disconnected). The files themselves are untouched and remain 
on the mass storage medium; they may be accessed by re-mounting the file system. 

In the file system’s superblock, there is an informational byte called the clean byte. 
When you create a file system the clean byte is set to FS.CLEAN. When you mount a 
file system, the clean byte is set to FS_OK. When you unmount a file system the clean 
byte is reset to FS.CLEAN. 

If you add your file system to /etc/checklist the /etc/bcheckrc program will mount 
and check the file system at bootup, /etc/bcheckrc uses the clean byte to determine if 
the system was properly shut down. If the clean byte is FS_OK (not FS.CLEAN), it 
was not unmounted with the umount command and could be corrupted, bcheckrc will 
run fsck if the clean byte is FS_OK (unless it is the root device) to correct corruption 
before continuing, /etc/rc mounts each file system in /etc/checklist after bcheckrc has 
checked them. 

For an explanation on how to add entries to the /etc/checklist file refer to the section 
“Adding to /etc/checklist”. 
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To Mount a File System 

The file system to be mounted must be initialized at some point with sdfinit (see the 
section called “Media Utilities” in this chapter). Initializing the file system with this 
utility insures the correct format for the Series 500 HP-UX file system. 

You must create a device file (if one does not yet exist) for the mass storage device 
containing the file system which is to be mounted. The special file must be a block 
special file; see the “Adding/Removing Peripheral Devices” section in this chapter for 
details. 

Before attempting to mount a file system, be certain the mass storage device associated 
with the file system is powered up and is on-line. If the file system is on removable 
medium (such as a flexible disk), insert the file system in the mass storage device at this 
time. Do not remove the flexible disk until its file system is unmounted. 

Decide what directory in the HP-UX file system will be used to mount the file system. 
It is best if you choose a directory that is at the root of the HP-UX file system. For 
example, /direct 

When a file system is mounted, the file system it contains is attached to a directory in 
the existing file system. Any files that the directory previously contained appear to be 
temporarily replaced by the file system contained on the mounted file system. Because 
of the confusion that may result (from the temporary “disappearance” of files in the 
mount directory), use only an empty directory created specifically for mounting. 

The diagrams that follow, for the sake of illustration, show a file system mounted on a 
directory that does contain files but this is not standard practice. Consider a directory 
called /direct that contains two files, filel and file2. Assume that you want to mount 
a flexible disk (that contains a hierarchical file system of its own as shown in the following 
illustration) on the /direct directory. The process of mounting the file system, modify¬ 
ing files on that file system, and unmounting the file system is shown in the following 
illustrations. 

Figure 5-2 shows the /direct directory on the existing mounted file system. It also shows 
the file system hierarchy on the as-yet-unmounted flexible disk file system. 
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Figure 5-2. File System Hierarchy Before Mounting 


Figure 5-3 shows the file system hierarchy once the flexible disk file system is mounted 
on the /direct directory. The file newf ile has been added to the flexible disk file system 
after it was mounted. Notice that the files filel and file2 previously available in the 
/direct directory are no longer accessible; the files are still there, they just cannot be 
accessed until the flexible disk file system is unmounted. 


The flexible disk file system was mounted with a command of the form: 

/etc/moimt /dev/fd_name /direct 

where /dev/fd_name is the special (device) file associated with the mass storage device 
containing the flexible disk and /direct is the directory on which the flexible disk file 
system is mounted. 
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Hierarchy of 
Mounted File System 



profile chapi newfile 


□ = directory 

Figure 5-3. File System Hierarchy After Mounting 

Figure 5-4 shows the /direct directory on the existing mounted file system after the 
flexible disk file system is unmounted. The filel and file2 files may once again be 
accessed. The diagram also shows the file system hierarchy on the unmounted flexible 
disk file system. 

The flexible disk file system was unmounted with a command of the form: 

/etc/umount /dev/fd_name 

where /dev/fd_name is the special (device) file associated with the mass storage device 
containing the flexible disk file system. 


224 The System Administrator’s Toolbox 




Hierarchy of File System of 

Existing File System Unmounted Flexible Disc Volume 



filel file2 .profile chap1 newfile 


//, 

Mj'-' 


(( 



n 

i i 

U 


□ = directory 

Figure 5-4. File System After Unmounting 


Note 

Always unmount a file system before removing it from its mass 
storage device. Removing a mounted file system from its mass 
storage device before unmounting it is likely to corrupt the file 
system. 


To Unmount a File System 

Use the following procedure to unmount a file system. 

1 . Make sure that all files on the file system are static; no one should be accessing 
any file on the file system. Attempting to unmount a file system that has open 
files (including your current working directory) causes the umount command to fail 
without unmounting the file system. 

2 . Enter the following: 

/etc/umount special_fname 

where speciaLfname is the pathname of the special (device) file of the device asso¬ 
ciated with the mounted file system. This command fails if there are open files on 
the file system you are attempting to unmount. 

3. When the shell prompt ($) is again displayed on your screen, it indicates that the 
file system is unmounted. If the file system is on a removable medium (such as a 
flexible disk), the medium can now be removed safely. 


The System Administrator’s Toolbox 225 





Errors 

You can’t unmount a file system that has open files. The following situations are the 
most frequent cause of open files on a file system: 

• having your current working directory on a file system causes an open file on the 
file system, 

• if a program stored on a file system is a shared program and the use count of that 
program is not zero, the file associated with the program is still open. 

• if a file has been accessed and the sticky bit is set in the file’s protection mode, the 
use count of the file is always greater than zero; the file is always open. 

If you get the error message, “cannot open /etc/mnttab”, there are two possible scenarios: 
either you were in the system administration mode (run-level s) and /etc/rc had not yet 
executed, or your /etc/rc script did not contain the setmnt command. If you are creating 
the /etc/mnttab file in the the system administration mode, you would use the following 
sequence: 

setmnt 
hd / 


If you need to add it to your /etc/rc file, one possible way is to add the following lines: 

setmnt «-! 
hd / 


Either method will create the mnttab file. From then on, each time you mount a file 
system, mount will automatically add entries into mnttab. 
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Mounting/Unmounting File Systems Using /etc/checklist 

If you wish to mount all the file systems (except root) listed in /etc/checklist, enter the 
foiiowing: 

mount -a 

The full path name where each file will be mounted must also exist in /etc/checklist. 

If you wish to unmount all file systems in /etc/checklist, enter the following: 
umount -a 

To automatically mount all file systems at bootup, add the mount -a entry to the /etc/rc 
file. To automatically unmount all file systems at shutdown, verify that the umount -a 
entry is in the / etc/shutdovm file. Refer to ‘‘Adding to /etc/checklist” in this chapter. 
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New Naming Conventions for Device Files 

To be consistent with the standard naming convention for mass storage device files, the 
HP-UX device file naming convention has changed. 

• All cartridge tape devices go in subdirectories: 

• raw (also called character) devices go in the /dev/rct directory, 

• block device files go in the /dev/ct directory. 

• All magnetic tape devices go in subdirectories: 

• raw (also called character) devices go in the /dev/rmt directory, 

• block devices go in the /dev/mt directory (currently unsupported, but re¬ 
served). 

• All hard disk and flexible disk devices go in subdirectories: 

• raw (also called character) devices go in the /dev/rdsk directory, 

• block devices go in the /dev/dsk directory. 

• No other devices are affected. 

On this release of HP-UX all commands will support both the old naming convention 
and the new naming convention. All examples in this manual reflect the new naming 
conventions unless the command or subsystem does not use new naming conventions. For 
example, although the installation procedure is shown in the old naming conventions, the 
backup procedure is shown using the new naming conventions. 

If you administer both S300 (or S800) and S500 HP-UX machines, you should change 
to the new naming conventions since the current Series 300 and Series 800 releases are 
installed with the new conventions. 
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To help you make the change, there is a new command: mvdevs. The syntax of the 
command is: 

mvdevs [-vilu] 

V The verbose option. This option prints information on your screen as it is execut¬ 
ing. 

i Interactive option. When you use this option mvdevs will ask you, for each device 
file, if you want to move it and if the name automatically chosen is acceptable. 

1 The long names option. With this option all device files will be renamed using the 
new naming convention as it is described in Section 7 of the HP-UX Reference, 
The default new naming convention is a shorter version of what is stated in the 
HP-UX Reference. 

u The undo option. This option will move all your device files back to their original 
names. This option can be used only if you have already run mvdevs. 

You cannot execute mvdevs in the background since it is an interactive process. The 
mvdevs script will not change the name of the /dev/update.src device file (the device file 
created and used by the update program). The mvdevs script will do the following: 

• move all your magnetic tape drive, cartridge tape drive, flexible disk drive, and 
hard disk drive device files to file names with the new naming convention (with the 
exception of /dev/update.src). 

• Change your existing /etc/backup, autobkup and /etc/checklist files to reflect the 
new device file names. 
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• create the following two files: 

• /etc/mvdevs.log 

This file is a log of the changes that were made. Single entries indicate new 
directories. Double entries indicate a moved file (the first entry is the from 
file, the second entry is the to file). You will notice that some files are first 
moved to a temporary file, then to their final destination. This is because 
their device file name was the same name as a new directory (dsk, rdsk, mt, 
rmt, ct, ret). 

• /etc/sed.mvdevs 

This file is a sed file that can be used to change files that explicitly name the 
old devices. The files will be changed to reflect the new device names. For 
example, if you have a script file that uses the old /dev/rct, and mvdevs has 
renamed it to /dev/rct/cO, the /etc/sed.mvdevs file will change the reference 
from /dev/rct to /dev/rct/cO. 

To use it, type: 

sed -f /etc/sed.mvdevs srefile > newfile 
mv newfile srefile 

where srefile is your original script file and newfile is a new (temporary) file. 
You then need to move (or copy) the new file back to the original name. Do 

not redirect the output to the original file name. If you do, you will destroy 
the original file and will have nothing. 
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Removing Optional Products and File sets 

If you are no longer using a file set, you should remove it so you have more space on 
your file system. The program /etc/sysrm performs the opposite of update; it removes 
optional file sets. 

1. Become the root user. 

2 . Determine which file sets you wish to remove. 

A directory, /etc/filesets, contains a complete list of file sets you have installed 
on your system. 

3. Shut down the system (refer to the section “Shutting Down the System” in Chapter 

4 ). 

4. Type in the following command, where fileset is the name or number of the product 
to be removed (determined in step 2): 

/etc/sysrm fileset 

The file set(s) you typed in will no longer be available. You can load them back into 
the system, if needed, by using the update procedure (Refer to “Updating HP-UX 
and Installing Optional Products”). 

5. Return your system to normal operating mode by typing in: 

reboot 
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Setting the System Clock 


The system clock should always have the correct time and date because a number of 
commands make use of the clock to accomplish their tasks. Occasionally, the system 
clock needs to be set or reset. There is no need to reset the system clock if you have 
shut the system down—your Series 500 computer has a battery which keeps the clock 
current. 


Only the effective super-user can change the system clock. To set the current time and 
date: 

1 . Login as the super-user root. 

2. Insure that the time zone environment variable TZ is set properly by typing in: 
echo $TZ (for more information refer to tzset under the ctime(3) entry in the HP- 
UX Reference manual). 

Typically, TZ’s value is set with a variable declaration (as shown below) in the file 
/etc/profile. It can also be set from an application program with the tzset library 
routine. 

As shipped to you, the system is set up to run in the Mountain Time Zone. To 
change the time zone to your time zone, modify the /etc/profile file to contain 
two entries of the form: 

TZ=XXXHYYY 
export TZ 

where XXX and YYY are three letter representations of the standard and daylight 
time zones for your area and H represents the difference between current local time 
and Greenwich Mean Time, in hours. The export TZ line will remain the same 
regardless of the time zone. For example, in Denver, Colorado you would enter the 
following: 

TZ=MST7MDT 
export TZ 

where MST stands for Mountain Standard Time and MDT stands for Mountain 
Daylight Time. 
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Here are some other examples: 

• For St. Clair Shores, Michigan: TZ=EST5EDT 

• For Norman, Oklahoma: TZ=CST6CDT 

• For Seattle, Washington: TZ=PST8PDT 

• For Hawaii: TZ=HST10 since Hawaii has no Daylight Savings Time. 

3. Now that the time zone is set, you can set the correct time and date (using the 
date command) by typing an entry of the form: 

date MMddhhmmfyy} 

MM A two-digit integer representing the month. For example, 03 
represents March. 

dd A two-digit integer representing the day of the month. For ex¬ 
ample, 02 represents the second day of the month. 

hh A two-digit integer specifying the current hour in terms of a 

twenty-four hour clock. For example, 03 specifies 3:00 am and 
14 specifies 2:00 pm. 

mm A two-digit integer specifying the number of minutes past the 

stated hour. For example, 04 specifies four minutes past the 
hour. 

{yy} An optional two-digit integer specifying the last two digits of the 
current year; this parameter may be omitted if the year is already 
correct. For example, 85 specifies 1985 as the current year. 

When date is executed it echoes the time and date on your screen. 

The make program (refer to the make(l) entry in the HP-UX Reference) is quite sensitive 
to a file’s time and date information and to the current value of the system clock. While 
setting the clock forward will not effect make, setting the clock backward by even a small 
amount may cause make to exhibit extremely bizarre behavior. Avoid setting times earlier 
than the current system clock’s value. 

As mentioned in the “Backing Up and Restoring the File System” section in this chapter, 
the process of making incremental backups depends heavily on the correctness of the date. 
This is because incremental backups are always made in relation to a dated file. 


The System Administrator’s Toolbox 233 



Altering the system clock may also cause some unexpected results for routines scheduled 
by cron; refer to the cron(l) entry in the HP-UX Reference. When setting time back, 
cron doesn’t run until the clock “catches up” to the point from which it is set back. For 
example, if you set the clock back from 8:00 to 7:30 (which is not advised), cron will not 
begin executing until the clock again reads 8:00. If you are setting the clock ahead, cron 
attempts to “catch up” by immediately executing all routines scheduled to run between 
the old time and the new time. For example, if you set the clock ahead from 9:00 to 
10:00, cron immediately executes all routines scheduled to run between 9:00 and 10:00. 

If you are only changing the clock by a small amount (20 - 30 minutes), cron’s behavior 
should not present a problem and no corrective action is necessary. However, if you are 
changing the clock by a larger increment, perform the following steps: 

1 . Log in as the super-user. 

2. Enter the following command: 

ps -ef 

to run the process status command and locate the cron process information supplied 
by ps. 

3. Terminate the cron process by entering the command: 

kill -9 pid 

where pid is the process id associated with cron. The ps command displays this 
number in a column labeled pid. 

4. Change the time and date with the date command. 

5. Start the cron process running again by entering the command: 

cron 
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Setting Up the LP Spooler 

HP-UX provides a series of commands, collectively referred to as the LP Spooler, to 
configure and control line printer spooling. Line printer spooling is a mechanism by which 
printing requests and their associated files get stored temporarily in a spool directory 
until they can be printed. The LP Spooler can be customized to spool to different printers 
and allow printers to be grouped into various classes to increase the overall efficiency of 
the system. Some of the LP commands are available to all users; others, only to the 
system administrator. The LP Spooler replaces the Ipr command; Ipr is a script which 
involves Ip, acting like the original line printer spooler. The LP Spooler is a superset of 
Ipr capabilities. 

What is in this Section 

This section explains how to set up and use the LP Spooler on your Series 500 HP-UX 
machine. It consists of the following subsections: 

• LP Spooler Terminology and Overview - an introduction to the LP Spooler. 

• Installing the LP Spooler - step-by-step method to install and start the spooler 
system. 

• General-purpose LP Spooler Commands - spooler commands available to all users. 

• System Administrator LP Spooler Commands - spooler commands available only to 
the system administrator (the root user). 

• Other LP Spooler Administrator Duties - tips on monitoring the spooler. 

• How Models Work - description of what a printer model is. 
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LP Spooler Terminology and Overview 

A request is a combination of one or more files to be printed and all associated information 
such as destination, number of copies, and other ip options. When Ip is invoked, it 
associates a unique ID with the request and passes the request to the LP scheduler 
(invoked by the Ipsched command). The LP scheduler routes the request to the proper 
interface program to do the actual printing on a device; the program functions as an 
interface between ipsched and printing devices. Models of interface programs are supplied 
with the LP Spooler and, in some cases, have options to use specific printer features such 
as expanded or compressed print. The models can be used as is, modified for your specific 
needs, or used as templates for creating new interface programs. 

The Ip command directs output to the default destination unless a destination is specified 
when Ip is executed. The default destination may be set or changed by the system 
administrator. A destination is either a printer or a class. A class is a name given to 
a list of printers. Each class must contain at least one printer although a printer may 
belong to zero, one, or more classes. If the destination is a specific printer, the output 
gets handled only by that printer. If the destination is a class, the output gets handled 
by the first available printer belonging to that class. 

A complete LP Spooler configuration for a system consists of devices, destinations 
(printer names and classes), interface programs, and the LP Spooler commands in the 
/usr/bin and /usr/lib directories. 

The LP Spooler distinguishes between logical destinations and physical destinations. 
Logical destinations are defined using the Ipadmin command whereas physical destina¬ 
tions are defined using mknod — which associates physical devices with special (device) 
files. A single physical destination may be associated with one or more logical destina¬ 
tions. Lp requests are directed to a logical destination as long as it has been set to accept 
requests (refer to accept(lM)), When a corresponding physical destination (a printer) is 
available and has been enabled (refer to enable(l)), the request is transferred to it. 
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Installing the LP Spooler 

To install and configure the LP Spooler, perform the following steps: 

1. Log in as the super-user (root). 

2. Check the following 3 configuration files: 

• /etc/passwd 

This file should have an entry providing ownership of the LP Spooler to the 
user Ip. There may be other users also associated with the group bin in your 
particular configuration. 

You may want to add password protection to the ip user. To do this, log in 
as the user Ip and execute the passwd command; refer to the passwdfl) entry 
in the HP-UX Reference for details. You can also prevent logins by putting 
an in the password field of the Ip entry. 

• /etc/group 

This file should have an entry providing group ownership of the LP Spooler 
to the user bin. 

• /etc/rc 

This file should contain commands to start up the LP scheduler every time 
the system is booted. As shipped, your /etc/rc file should contain the lines: 

# Start Ip printer scheduler, if configured 
/usr/lib/lpshut > /dev/null 2>&1 
if [ “S /usr/spool/lp/pstatus ] 
then 

/usr/lib/lpsched 

echo line printer spooler started 
fi 

The three configuration files are set up correctly when you install your system. If 
you update your system, check the file /etc/neweonfig/Update_info for details on 
your new revision of HP-UX. 
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3. Edit the /etc/mklp script. 

You will use the /etc/mklp script to configure your LP Spooler and set up your 
printer device files. For each type of printer you have, you must edit the script in 
the following manner: 

a. Remove the lines that appear just before section 1: 

echo "mklp: temlplate version -- customize script before using it" 
exit 1 

b. Uncomment (i.e., remove the in column 1) all the command lines appli¬ 
cable to the printer you are setting up. 

c. If necessary, change the names of select code (sc), bus address (ba). and 
unit/volume (uv) to correctly describe your printer. 

d. If the printer will function as the default printer, the name and dev values 
should both be set to Ip. If it will serve as an ausiliary printer, the name and 
dev values should be changed to the device file name of the auxiliary printer. 


NOTE 

If you have a system printer, you should always name its corre¬ 
sponding special file /dev/lp, because some commands use this 
special file as a default. You can create an individual special file 
for your favorite printer and give it the pathname /dev/lp (there is 
one created for you during system installation). Alternately, you 
can take an existing special file for the printer and create a link to 
it from the pathname /dev/lp. 
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4. Execute the /etc/mklp script. 

When you have correctly edited the /etc/mklp script (see step 3), type: /etc/mklp 
i Return | . The script will perform the following steps for each printer: 

a. Make the correct special device file for the printer. 

b. Shut down the LP scheduler. 

c. Execute the Ipadmin command with the printer name (-p option), special 
device file name (-v option), printer model name (-m option), and any other 
appropriate options. 

d. Execute accept and enable to allow requests to reach the printer. 

e. Restart the LP scheduler with the ipsched command. 

The script then executes the ipadmin command with the -d (default) option 
to select the default printer name. Usually the default printer name is Ip. 

5. To see that the LP spooler’s “scheduler” is properly running, execute: 

Ipstat -t 

6. If the scheduler is terminated improperly, you may need to remove the file SCHED- 
LOCK before the scheduler will begin working. Do this by typing: 

rm -f /usr/spool/ lp/SCHE DLOCK | Return | 

/usr/lib/lpsched | Return | 

The SCHEDLOCK file acts as a “semaphore” to keep more than one scheduler from 
running at any given point in time. The Ipshut command automatically removes 
the SCHEDLOCK file when it terminates the LP scheduler. 
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Example 

Assume, for example, that you want to set up an HP 2225A Thinkjet printer as a spooled 
device, and you want to make it the system printer (the default printer). The printer is 
on the HP-IB at select code 5, bus address 1. To install the printer, perform the following 
steps: 

1. Edit the /etc/mklp script: 

a. find the reference to “HP 2225A” in “SECTION TWO” of the script. 

b. Change the select code (sc) from “??” to “05”. 

c. Change the bus address (ba) from “??” to “01”. 

d. Change the unit and volume (uv) from “??” to “00”. 

e. Uncomment (i.e., remove the # in the first column) each line in the script 
from cd /dev to $ipsched. 

2. Execute the /etc/mklp script by typing: 

/etc/mklp 


Once this is done, your HP 2225A printer is installed and you can send files to it (through 
the spooler system) by issuing commands of the form: 

Ip myfile 

where myfile is the name of the file you wish to print. 
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General-Purpose LP Spooler Commands 

The following is a brief overview of the LP Spooler commands available to all users; for 
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• cancel Cancels requests to an LP Spooler line printer made with the Ip command. 
The user may address a specific printer or a specific request ID number. Refer to 
the lp(l) entry in the HP-UX Reference. 

• disabled) Disables one or more physical printers such that they will not print 
Ip requests. Refer to the enable(1) entry in the HP-UX Reference. 

• enable Activates one or more physical printers to print Ip requests. 

• Ip Sends requests to an LP Spooler line printer. Requests are files and associated 
printing information (flags, etc.) sent to the spooler. The Ip command returns (to 
standard output) a unique ID associated with a request. 

• Ipstat Prints current LP Spooler status information such as requests, IDs, and 
scheduler information. 


System Administrator LP Spooler Commands 

The following commands are available only to the system administrator (the user root) 
or the LP Spooler administrator (the user Ip). Further details are contained in this 
section and in section IM the HP-UX Reference manual. 

• accept Allows Ip requests to occur on one or more logical destinations where a 
“destination” is a printer or class of printers. 

• Ipadmin Configures the LP Spooler system by describing printers, classes, and 
devices. The LP scheduler must not be running when most ipadmin command 
options are used. 

For example, if you have an HP2934A that is accessible through the device file 
/dev/lp, you can use the following command line: 

/usr/lib/lpadmin -pip -v/dev/lp -mhp2934a -h 

-pip specifies the printer. The logical destination name is Ip. 

-v/dev/lp specifies the full path name of the printer’s special (device) file — the 
physical destination. 

-mhp2934a specifies a model in the /usr/spool/lp/model directory. 

-h specifies that the printer is “hard-wired”. 
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• Ipmove Moves requests queued by the LP scheduler from one destination to an¬ 
other. The LP scheduler must not be running when ipmove is used. Refer to the 
Ipsched(lM) entry in the HP-UX Reference. 

• ipsched Schedules requests taken by ip for spooling to line printers. 

• ipshut Shuts down the LP scheduler. Refer to the Ipsched(lM) entry in the 
HP-UX Reference. 

• reject Rejects Ip requests on one or more logical destinations where a “destina¬ 
tion” is a printer or class of printers. Refer to the accept(lM) entry in the HP-UX 
Reference. 

Other LP Spooler Adminstrator Duties 

There arc several other activities that you may need to carry out as the system admin¬ 
istrator of the LP Spooler system: 

• determining the current status of the LP Spooler system; 

• starting and stopping the LP scheduler; 

• grouping printers into classes; 

• removing destinations (printers and classes of printers); 

• moving requests to other destinations. 

Determining LP Spooler Status 

The command Ipstat has options that provide a variety of information about your LP 
Spooler system. Used without any options, ipstat prints the status of all requests that 
you have made to ip and the -t option gives complete LP Spooler status information. 
For example, ipstat -t results in output similar to: 

scheduler is running 

system default destination: Ip 

device for Ip: /dev/lp 

Ip accepting requests since Jun 14, 15:37 


printer Ip 

now printing lp-165. 

enabled 

since 

Jun 

23 13:31 

lp-165 

williams 

62489 

Jul 

9 

12:53 on Ip 

Ip-166 

Jones 

1374 

Jul 

9 

13:39 
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The options that you can specify with Ipstat are: 

-8i[listl Print the request acceptance status (with respect to Ip) of logical destina¬ 
tions. List is a list of intermixed printer names and class names. If you do 
not specify list^ the acceptance status of all logical destinations is printed. 

-cllistj Print class names and their members. List is a list of class names. If you 
do not specify list^ all classes and their members are printed. 

-d Print the system default destination for ip. 

-oflist] Print the status of requests. List is a list of intermixed printer names, class 

names, and request IDs for which you want request status. If you do not 
specify list, ipstat -o has the same effect as Ipstat (with no options). 

-p[list] Print the status of printers. List is a list of logical printer names. If you 
do not specify list, the status of all printers is printed. 

-r Print the status of the LP scheduler. 

-s Print a status summary that includes the status of the LP scheduler, the 

name of the system default destination, a list of class names and their 
members, and a list of logical printers names and their associated special 
(device) file names. 

-t Print all status information. 

•’yxflist] Print the status of requests for particular users specified by the login named 
in list. If you do not specify list, the status of all users’ requests is printed. 

-v[list] Print the pathnames of the physical devices associated with the logical 
printer names specified in list. If you do not specify list, the names of all 
of the logical printers and their associated physical devices are printed. 

You can specify any combination of the above options on an ipstat command line. 

In addition to using zero or more of Ipstafs options, you can also follow the command 

with particular request IDs, in which case ipstat provides status information about those 

requests. 
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Controlling the LP Scheduler 

The LP scheduler services all Ip requests by routing them to an interface program as¬ 
sociated with the specified printer or class of printers. Interface programs control the 
actual printing on the devices. 

To start the LP scheduler running, use: 

/usr/lib/lpsched 

The scheduler must be running for the LP Spooler to be available for use. However, you 
must shut down the scheduler before using either Ipadmin or Ipmove. To shut down the 
scheduler, use: 

/usr/lib/lpshut 

Remember to re-start the scheduler once you are through using Ipadmin or Ipmove. 

Building Printer Classes 

A class is a name given to a group of one or more printers. When requests are sent to a 
class, they are serviced by the first available printer that is a member of that class. 

The -c option of the Ipadmin command inserts a printer into a particular class. If the 
class does not already exist, it is created. If the class does exist, the printer is added. 
For example, you could associate the printer described above to a class with: 

/usr/lib/lpadmin -pip -cclassl 

This creates the class classl (unless it already exists) and inserts the printer ip into it. 

Removing Destinations 

LP Spooler destinations (printers, classes, or both) are removed with the Ipadmin com¬ 
mand. To remove a printer from a specific class, use Ipadmin's -r option: 

/usr/lib/lpadmin -pip -rclassl 

Removing the last remaining member of a class causes the class itself to be deleted. In 
the example above, since Ip is the only member of classl, the class is deleted. 

To remove an entire class of printers, use ipadmin ’s -x option: 

/usr/lib/lpadmin -xclassl 

To remove a printer that is not a member of a class, use ipadmin's -x option as follows: 
/usr/lib/lpadmin -xlp 
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Note 

No printer or class of printers can be removed if it has any pending 
requests. You can use Ipmove or cancel to move or delete the 
requests. 


Moving Requests 

Occasionally it is useful to move requests from one destination to another, such as when 
one printer is down for repairs. The Ipmove command is provided for this purpose. 
Before using the command make sure that Ipsched is not running. To shut down the LP 
scheduler, execute: 

/usr/lib/lpshut 

You can use Ipmove in one of the following ways. 

• Move all requests for printer Ipl to printer lp2: 

/usr/lib/lpmove Ipl lp2 

• Move the request with the ID Ipl-103 to printer lp2: 

/usr/lib/lpmove Ipl-103 lp2 

Lpmove never checks the acceptance status of the new printer (whether or not accept has 
been executed on it) when it moves requests; therefore, you should execute: 

Ipstat -alp2 

to see if lp2 can accept requests before actually redirecting requests to it. 


Note 

Moving requests from one printer to a dissimilar printer may cause 
incorrect output. The options specified by the user for the original 
may be meaningless on the new printer. 
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How Models Work 

Models are shell scripts, C programs, or other executable programs that interface between 
Ipsched and devices. Several model scripts are shipped with your system and are located 
in the /usr/spool/lp/model directory. As shipped to you, this directory includes model 
scripts for a generic “dumb” printer, the HP 2225A, HP 2631G, HP 2686A, HP 2688A, 
HP 2934A, and the HP 9000 Model 520 internal thermal printer. These model scripts 
must have a permission mode of 644 and be owned by ip and group bin. Refer to the 
/etc/mklp script for a description of the provided models. 

If you want to modify one of the models for your system needs, make a copy of it, modify 
the copy, and then associate the copy with a printer using Ipadmin with the -i (interface) 
option. 

Refer to Ipadmin(lM) for more details on models. 
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updating HP-UX and Installing Optional Products 

This section describes the steps necessary to update your HP-UX system, as well as how 
to install optional products such as the SRM access utilities (Shared Resource Manager), 
LAN (Local Area Network) and optional partitions of your operating system. Since the 
process of updating or installing optional products could involve changes to the HP-UX 
kernel, you should carefully follow the preparatory steps below before proceeding. Note 
that the procedure is exactly the same for updating and for optional product installation. 
You should read the definitions and discussion in the first part of chapter 2 (“Installing 
HP-UX”). 


An overview of the entire update procedure is; 

1. prepare the system for an update 

2. locate the product (optional product, operating system update, or optional parti¬ 
tion), 

3. load the update tools if you are updating your operating system, 

4. perform the update, 

5. exit the update program 

6. Check for additional information in the Installation Notes or in the files in the 
/etc/newconfig/Update^inf o directory. 

Each of these 6 steps is described in the following subsections. 

Preparing to Update 

The HP-UX kernel could be modified when you update the system. Because of this, it is 
always possible to crash your disk while updating. By following these simple steps, you 
will be able to minimize any risks to the integrity of your computer system and data. 

Shut Down Your System 

You do not need to specify any option, other than the grace period, when shutting down 
the system for an update. For more information, refer to the section “Shutting Down 
the System” in Chapter 4. 
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Do an fsck 

Now that your system is in single-user mode, you can (optionally) do a file system check 
using the fsck command. Your system probably does not need to be fscked (particularly 
if you regularly check it). For more on how to use the fsck command see Appendix A, 
“Using the FSCK Command”. 

Mount all File Systems 

After you have shutdown and checked (fsck) your system, you must mount all file sys¬ 
tems. To do this, you must first create the /etc/mnttab file using the following procedure. 

1. Enter the command: 

devnm / 

a. If it returns one line, enter: 

devnm / I setmnt 

b. If it reiunis more than one line, determine which device is your root file system 
and pipe that to the setmnt command. For example, if your root file system 
is hd, then you would enter: 

devnm / I grep hd I setmnt 

2. You must now mount all file systems other than root. If your file systems are 
in the /etc/checklist file, type mount -a. If your file systems are not listed in 
/etc/checklist, you must explicitly mount them. If you have a file system on 
/dev/hdl that you wish to mount as /dl, you should use the command line: 

mount /dev/hdl /dl 

Refer to the section “Mounting and Unmounting File Systems” for more informa¬ 
tion. 

Back up your file system 

If you make a mistake, and possibly corrupt your file system while updating your com¬ 
puter, you should be able to recover all of your data if you have adequately backed up 
your system. Refer to the “Backing up and Restoring the File System” section of Chap¬ 
ter 5 (“The System Administrator’s Toolbox”) for more information on how to archive 
your system. 
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Find /dev Major and Minor Numbers 

You need to know the major and minor numbers of the drive used to read the update 
media, and for the hard disk being updated as well. Be sure you know the correct values 
of these numbers before you continue. You can obtain this information by typing: 

11 fde'v/source /d.ev/dest 

where source is the tape drive your update will be loaded from, and dest is the hard disk 
you will be updating (probably your root disk). Make sure you write these values down, 
because the /etc/update program uses screen menus—you won’t be able to “scroll” back 
to find these numbers. 

Locate and Write-protect the Product 

Locate the write-protect mechanism (labeled “SAFE”) on the top, rear, left-hand corner 
of the cartridge tape. The arrow on the protect screw should point toward the word 
SAFE. If it does not, use a coin or screwdriver to turn the protect screw such that the 
arrow points toward the word SAFE. Place this tape in the CS/80 data cartridge drive 
connected to your system with the SAFE label in the rear left hand corner. Only the 
BUSY and PROTECTED indicators should now be lit. The drive will begin a cartridge 
tape conditioning sequence that takes approximately two minutes. Do not proceed until 
the busy light remains off. 

Load the Update Tools 

The update tools need to be loaded ONLY if you are updating your operating system 
with a new set of update media. If you are adding an optional partition or loading an 
optional product, you do not need to load the update tools. If you are not updating your 
operating system, go to the section called “Perform the Update”. 

If you are updating your operating system, type in: 

lifcp -a /dev/sowrce: GETTOOLS /tmp/gettools 
chmod 700 /tmp/gettools 
/tmp/gettools fdev/source 
rm /tmp/gettools 

where the device /dev/source is the character special device file name assigned to the 
cartridge tape drive you just inserted the update media in. Executing /tmp/gettools 
causes any new tools related to the update process to be extracted from the media 
and put into your current file system. This could take from one to several minutes to 
complete. 
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Perform the Update 


Note 

Before you perform the update, you must have completed the 
preparatory steps to ensure your system is ready. You must have 
copied the major and minor numbers of the cartridge tape drive 
the update will be on, and the major and minor numbers of the 
disk you will be performing the update to (usually your root disk). 


If you have a non-HP terminal, you MUST execute the update program with a -m option. 
This will turn off all the menus in the update program. You will be prompted for the 
appropriate choices, rather than see the menu, on your screen. 

1. Type in: 

/etc/update 

Your system will reboot to remove any remaining processes. You will see your 
normal boot messages, and then the screen should clear and the menu shown in 
Figure 5-5 will appear. This is the main update utility menu. All update procedures 
are treated as sub-tasks from this menu. 
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HP-UX UPDATE UTILITY — MAIN MENU 
Select Choice 

Source Device Destination Device 


Major Number = -1 
Select Code = -1 
Bus Address = -1 
Unit Number = -1 
Volume Number = -1 


Major Niimber = 1 
Select Code = 4 
Bus Address = 1 
Unit Number = 0 
Volume Number = 0 


DISPLAY options for a new partition 
EXIT update 
CHANGE source device 
CHANGE destination device 


Figure 5-5. Main Utility Menu 

Note the four softkeys at the bottom of your screen: 

• NEXT will move the highlight to the next item in each menu. 

• PREVIOUS will move the highlight to the previous item in each menu (the item 
listed above the current item). 

• SELECT will execute the currently highlighted option. 

• QUIT will exit the update program at any time. 

The source device will be listed as either the source device used in the last update 
or as all -Is. The destination device will be your root disk. If the source device is 
shown as all -Is it must be changed. 

2. CHANGE the source device. 

By using the NEXT and PREVIOUS softkeys, choose the “CHANGE source device” 
option on the main menu and press SELECT. You will see the top half of the menu 
shown in Figure 5-6. 
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HP-UX UPDATE UTILITY -- MAIN MENU 
**♦**♦♦♦**♦♦♦♦♦♦♦♦****♦****♦♦♦**♦♦♦♦♦♦♦♦♦♦****♦***♦♦♦♦♦♦♦ 

Current Source Device 

Major Number = -1 
Select Code = -1 
Bus Address = -1 
Unit Number = -1 
Volume Number = -1 

NEW Major Number? 1 
NEW Select Code? 4 
NEW Bus Address? 5 
NEW Unit Number? 0 
NEW Volume Number? 0 


Figure 5-6. Change Device Menu 

As you are prompted for each item, enter the source device’s major number, select 
code, bus address, unit and volume numbers in decimal format. You have these 
numbers written down in hexadecimal format. In our example the major number 
was 4, and the minor number was 0x070400 in hexadecimal format (do not type in 
any leading zeros for these values). The minor number has the format: 

OxScBaUV 

where Ox indicates the number is in base 16, Sc is the select code, Ba is the bus 
address, U is the unit number, and V is the volume. 

Once you have entered the volume number, the main menu will appear. Notice 
that the new source device values are now shown. Check that the values shown on 
the menu match those you have written down. It is possible that you could make 
a mistake while converting from hexadecimal to decimal format. 

3. CHANGE the destination device. 

You generally will not need to change the destination device. Change the destina¬ 
tion device ONLY if you are updating a disk other than your root disk. 


252 The System Administrator’s Toolbox 



Use the NEXT and PREVIOUS softkeys to choose the “CHANGE destination device” 
option on the menu and press SELECT. You should now see a screen very similar 
to the menu shown in Figure 5-6, only you will be changing the destination device 
rather than the source device. 

In exactly the same manner as you just changed the source device, enter the new 
destination device major and minor numbers, which you have written down. We 
will use major number 0 and minor number 0x0e0500 in our example. 

Once you have entered the new volume number, the update program will attempt 
to mount the device you have listed at that address. If it is the root device (which is 
the normal case), the following prompt will appear near the bottom of the console: 

Cannot mount the destination device. 

Is this the ROOT device? (’y’or^nO >> 

Because the method of updating the root file system versus another hard disk is 
different, you must tell the program that you are indeed updating the root file 
system by typing fYl - Otherwise, you should enter an rn~1 » 

Once you have entered the correct addresses for the source and destination devices, 
you see these values reflected in the main menu, similar to our example menu in 
Figure 5-7. If either of these values are wrong, you can go back to change either 
the source or the destination device. Do not continue if you are unsure of these 
values! Use the QUIT softkey if you are not sure of these device addresses, and go 
back to step 1 to begin again. 
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HP-UX UPDATE UTILITY -- MAIN MENU 
Select Choice 

Source Device Destination Device 


Major Number = 1 
Select Code = 4 
Bus Address = 5 
Unit Number = 0 
Volume Number = 0 


Major Number = 1 
Select Code = 4 
Bus Address = 1 
Unit Number = 0 
Volume Number = 0 


DISPLAY options for a new partition 
EXIT update 
CHANGE source device 
CHANGE destination device 


Figure 5-7. Main Menu After Changing Devices 

4. Choose the “DISPLAY” option. 

Using the NEXT and PREVIOUS keys, choose the “DISPLAY options for a new 
partition” menu item and press SELECT. The update procedure will now read the 
update tape to get a list of available options, which takes a couple of minutes. You 
should see the screen shown in Figure 5-8. 
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HP-UX UPDATE UTILITY -- READING FILE MENU 

******** *********** 


reading 


Please insert media for a new partition. 

When the busy light goes off, press [Return] 


Figure 5-8. Reading File Menu 


If you loaded new update tools, then the correct media is already inserted and you 
need to press | Return | . If you did not need to load new update tools, then you can 
insert the media now, and press | Return | . 

The update procedure will read the tape, and a new main menu will appear. 

5. You will see a menu similar to that in Figure 5-9. On the new menu, notice a 
product name on the upper left segment of the screen, and the list of product “file 
sets”. 
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Partition: ”16-USER-5.1" Media Number: "1" 

HP-UX UPDATE UTILITY -- MAIN MENU 
select choice 


Load "97089C" file set 
Load "97081C" file set 

Process ALL file sets 

DISPLAY options for a new partition 

EXIT update 

CHANGE source device 

CHANGE destination device 


Figure 5-9. File set menu for Update 


At this point you have several options: 

• If you wish to load all the file sets at one time, use the softkeys to select the 
Process ALL file sets option. This procedure could take 20 to 60 minutes 
depending upon the processor and peripherals being used. 

• If you wish to load just the core system (basically the update for HP-UX 
itself), use the softkeys to select the option similar to Load ''97089C" file 
set. Note that in each “Load xxxxxx” option, the xxxxxx is the product 
number or name for that file set. 

• If you wish to load the core system and certain optional products, select the 
options you want. 

You will select one load option at a time. Each time, that file set will be 
loaded, and you will return to the file set menu. When you have loaded all 
the file sets you wish, press the QUIT softkey to exit. You will be returned to 
the main menu, shown in Figure 5-9. 
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• If you wish to load a second product, unload the current tape, insert the new 
tape, and when the busy light remains off select the DISPLAY options for a 
new partition option. You will be returned to a new menu similar to Figure 
5-9. Continue with step 5. 

• If you wish to abort the entire update procedure, select the “EXIT update” 
menu item. 

The update program will immediately load this file set if it has never done so 
previously. If it has loaded the file set, the update program will inform you that 
the product exists on your system and asks you if you want it removed. | y | will 
remove the old file set, and re-load the new one. Answering j n ! will prevent this 
file set from being loaded. 

When the selected option is complete, the main menu (similar to the menu shown 
in Figure 5-9) will be re-displayed, but with one or more of the “load” options 
removed. Those options corresponding to the file sets you have already loaded will 
not be displayed. If you decided to load all the file sets, there will be no “load” 
options displayed. 

6. Leave the update program. 

If you have loaded all the products you want in this session, select the EXIT update 
option on the main menu. The program will inform you that it is unloading the 
media, which will take a few minutes. The system will reboot. 


Note 

Do not cycle power during the reboot. 


The reboot of your system may appear to take longer than normal. This is because 
the first time you reboot after doing an update, scripts execute which customize 
your system for the updated products you installed. 

7. Check for Additional Information. 

Following this reboot process, you should log in and check to see if you have 
files in /etc/newconfig/Update_info. Also look for any other update files in the 
/etc/newconfig directory or in the /tmp/update.log file. Follow instructions in 
these files, and instructions in the Installation Notes, if supplied. The file called 
README contains useful information about your updated system. 
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Using Optinstall to Install Optional Products 

Most of the optional products on HP-UX should be installed using the update procedure 
documented in the section “Updating HP-UX and Installing Optional Products'’ earlier in 
this chapter. If your optional product requires you to use optinstall, use the information 
in this section. 

1. The optional product is supplied on cartridge tape for installation from your car¬ 
tridge tape drive. 

Examine the supplied cartridge tape containing the product. Locate the write- 
protect mechanism (labeled “SAFE”) at the front upper right-hand corner of the 
medium. Make sure the arrow is pointed to “SAFE.” If it is not, using a coin or 
screwdriver, turn the protect screw such that the arrow is pointed toward the word 
“SAFE.” 

2. Determine from which device you want to load the tape’s data. This is the “source 
device.” 

3. Power up the source device. After the drive’s buzzer has sounded, insert the car¬ 
tridge tape into the cartridge tape drive. Wait for the drive’s busy light to extin¬ 
guish before continuing. 

4. Log in as the super-user and execute the following command: 

optinstall product_number [unload] [debug] 


where product_number is the product number of the option to install. If the unload 
keyword is specified, the cartridge tape is automatically rewound and unloaded at 
the end of the update. Refer to optinstall (8) in the HP-UX Reference manual for 
additional information. The following are some typical examples: 

optinstall 97071A 
optinstall 97059A 

The exact entry is the same as that listed on the spine of tape cartridge for that 
product. 

The system responds by printing the following on the system console: 

HP-UX FEATURE PRODUCT INSTALLATION UTILITY 
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5. The system then lists the default parameters for the utility: 




A 


Here are the default parameters for this installation: 

* Source device: 88140 L/S tape cartridge 

select code = 5 

bus address = 0 

unit number = 1 

* Destination device: HP-UX root volume 

Are these values satisfactory for your system? 

If they are not, you will be instructed to supply 
responses for each parameter, interactively. 

(Enter y or n, then RETURN; default is ’yes*) 


When an option is incorporated into the operating system, the file system is altered. 
The destination device specifies which file system is altered. The default is the 
current root file system. 

6. If the displayed parameters are correct, enter y, then continue with Step 10. 

If you want to change one or more of the parameters, enter n, and continue with 
step 7. 

7, If you typed a negative answer, you are prompted to identify the source device: 


r 




* Source device: 88140 Cartridge Tape Drive 

select code = 5 

bus address = 0 

unit number = 1 

Do these parameters accurately describe our source device? 

(Enter y or n, then RETURN; default is ’yes’) 


If the source device is correctly identified, press | Return | to select the default response 
(yes) or enter y. Continue the installation procedure with step 8. 
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If the source device is not correctly identified, enter n (then continue the installation 
procedure with step a): 

a. The system next prompts to find the select code of the source device: 

Enter the select code of your 88140 tape drive. 

The range for the select code is 0 through 23, inclusive. 

Enter the select code of the source device, then press | Return | , Entering no 
value (simply pressing | Return | ) causes the most recently entered value (or the 
default value, if it has never been changed) to be used. 


Note 

When asked to enter numerical information (such as a select code 
or bus address), do not use leading zeros with the values you enter. 
For example, to specify the value 7, enter 7, not 07 or 007. Use of 
leading zeros can cause unexpected results. 


b. The system next prompts to find the bus address of the source device: 

Enter the bus address of your 88140 tape drive. 

The range for the bus address is 0 through 1, inclusive. 

Enter the bus address of the source device, then press | Return ! . Entering no 
value (simply pressing | Return | ) causes the most recently entered value (or the 
default value, if it has never been changed) to be used. 

c. The system next prompts to find the unit number of the source device: 

Enter the unit number of your 88140 tape drive. 

The range of the unit number is 0 through 1, inclusive. 

Enter the unit number of the source device, then press | Return | . Entering no 
value (simply pressing | Return | ) causes the most recently entered value (or the 
default value, if it has never been changed) to be used. 
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8. Next, you are prompted to identify the destination device: 

♦ Destination device: HP-UX root volume 

Is your destination device correctly described? 

(Enter y or n, then RETURN; default is *yes’) 

If the destination device is correctly identified, enter y, then continue the installation 
procedure with Step 9. 

If the destination device is not correctly identified, enter n, then continue the in¬ 
stallation procedure with Step a. 

a. The system next prompts to find the select code of the destination device: 


Enter the select code of the destination device. 

The range for the select code is 0 through 23, inclusive. 

Enter the select code of the destination device, then press i Return | . Entering 
no value (simply pressing | Return | ) causes the most recently entered value (or 
the default value, if it has never been changed) to be used. 

b. The system next prompts to find the bus address of the destination device: 

Enter the bus address of the destination device. 

The range for the bus address is 0 through 7, inclusive. 

Enter the bus address of the destination device, then press | Return | . Entering 
no value (simply pressing | Return | ) causes the most recently entered value (or 
the default value, if it has never been changed) to be used. 

Since the unit number of the destination device must be zero (0), you are not 
prompted for this value. 

9. Next the system displays the menu of default value shown in step 5 previously (the 
new values you entered during the prompting sequence replace the original values 
displayed). And again, you are prompted to specify whether or not the values 
displayed are valid for system installation. Continue the installation procedure 
from step 5. (This time, the values shown for each installation parameter are the 
values you specified in steps 5 through 8.) 


The System Administrator’s Toolbox 261 



10. Now that all of the parameters for the installation program are correct, the system 
prompts you to re-examine the values and make sure that they are accurate: 

Are you sure you are ready to begin the installation/update procedure on 
the destination disk? 

(You should have a current backup of your file system!) 

(Enter y or n, then RETURN; default is ’NO’!) 

If you are NOT satisfied with the installation parameters, either press | Return | (se¬ 
lecting the default answer NO) or enter n. The program terminates. Restart the 
procedure at step 4. 

If you are satisfied with the parameters and are ready to begin the installation 
or update, enter y. The system begins the installation and supplies the following 
comments as it proceeds. 

Mounting the source device. 

Checking the source device for product 97xxxA 
Installing/Updating the 97xxxA product. 

The system then lists files for the product that are being installed. Once all the 
files have been installed, the following message appears: 

THE UPDATE/INSTALLATION OF HP-UX FEATURE PRODUCT ON THE 
DESTINATION DISC IS NOW COMPLETE. 

To install another optional product, go back to step 4 of this procedure. 

If the unload keyword was not specified when you invoked optinstall, the tape is 
not automatically rewound after an option installation. To rewind and unload the 
tape manually, execute: 

tcio -urV /dev/rmt 

The above example assumes that /dev/rmt is the special file for the cartridge tape 
drive. To perform tcio to rewind your tape, you may have to create a special file for 
the drive using mknod. Refer to the “Adding/Moving Peripheral Devices” section of 
this chapter. 

This may take a few minutes to execute, so it is useful to do it in the background. 
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System Accounting 


V 


Multi-user HP-UX allows concurrent sharing of computer resources among multiple users: 
several users can be logged in, all sharing disk space, memory, and the CPU. On multi¬ 
user systems, HP-UX System Accounting provides the means to: 


• monitor disk space usage for individual users 

• record connect session data (logins/logouts) 

• collect resource utilization data (such as memory usage, and execution times) for 
individual processes 

• charge fees to specific users 

• generate summary files and reports that can be used to analyze system performance 
and bill users for resource consumption 
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What Is in This Chapter? 

HP-UX System Accounting allows you to accomplish accounting tasks through a number 
of versatile commands. This chapter illustrates the use of these commands and contains 
the following sections: 

• “Installation and Daily Usage” shows the routine daily usage of System Accounting 
and shows you how to install it. 

• “Overview of System Accounting” provides the background information necessary 
to understand how to use System Accounting, 

• “Disk Space Usage Accounting” illustrates the use of the accounting commands 
that monitor disk space utilization on a per-user basis. 

• “Connect Session Accounting” describes the commands that record and report 
connect session accounting information. 

• “Process Accounting” shows how to generate per-process accounting data and re¬ 
ports. 

• “Charging Fees to Users” is the section where you learn how to charge fees to users. 

• “Summarizing and Reporting Accounting Information” shows how to generate the 
main daily and monthly accounting reports that are used to monitor system per¬ 
formance and bill users. 

• “Updating the 

Holidays File” describes how to set up the file /usr/lib/acct/holidays on your 
system. 

• “Fixing Corrupted Files” Occasionally, during day-to-day usage of System Account¬ 
ing, certain files may become inconsistent or messed up; this section shows how to 
fix these files. 

• “Sample Accounting Shell Scripts” provides listings of shell scripts that you might 
find useful on your system. 

In addition to these sections, the section “System Accounting Files” contains brief defi¬ 
nitions of all the files used by System Accounting. 
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Note 


Much of the material in this chapter assumes greater knowledge of 
HP-UX than is required of the “average” user. In particular, Sys¬ 
tem Accounting borrows many concepts from the previous chapters 
“Concepts”, and “System Boot and Login.” If you are unfamiliar 
with the concepts and terminology in those chapters, then you 
should review them. 


Installation and Daily Usage 

Now that the basics have been covered, you can start learning how to use System Ac¬ 
counting on a daily basis. The purpose of this section is to show you: 

1. What you must do to get Accounting running on your system. 

2. How System Accounting automatically creates daily and monthly accounting data 
and reports. 

After reading this section, you should be able to install Accounting on your system. Once 
properly installed, Accounting will automatically generate daily and monthly accounting 
data and reports. 

How to Install System Accounting 

Not all users require accounting services on their systems. For this reason, HP-UX 
System Accounting is provided as an option: if you want to use Accounting, you must 
install it yourself. Installation procedure is covered here. 

There are four steps in the installation process: 

1. Updating /etc/rc 

2. Updating /etc/shutdown 

3. Creating crontab entries 

4. Setting PATH for accounting commands 

Each of these steps must be carried out to insure that System Accounting automatically 
creates daily and monthly accounting information. Detailed descriptions of each step 
follow. 
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Updating /etc/rc 

The system initialization shell script rc must be updated to automatically start System 
Accounting when the system is switched into multi-user mode. This requires adding the 
following entry in the state 2 section: 

/bin/su - adm -c /usr/lib/acct/startup 

Updating /etc/shutdown 

To insure that accounting is turned off when the system is brought down via shutdown, you 
must add the shutacct command to the shutdown shell script. The call to shutacct should 
be placed in the section of shutdown where all processes are killed by the /etc/killall 
command. By calling shutacct after killall, process accounting information can be 
captured for the processes that were terminated by killall. The entry for the shutacct 
command should be made as follows: 

/usr/lib/acct/shutacct 


Note 

If you do not use /etc/shutdown to bring your system down, 
then you should use some other means—such as turnacct off or 
shutacct by itself—to turn system accounting off before shutting 
down your system. 
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Creating crontab Entries 

To automate the daily and monthly creation of accounting data, you should create a 
crontab file that cron can use to autom.atically run certain accounting commands. This 
process entails the following steps: 

1. Log in to System Accounting as the user adm. 

2. Use an editor to create the crontab file containing the accounting commands that 
are to be run automatically by cron. (The actual entries to make in this file are 
shown after these steps.) 

3. Execute the crontab(1) command, specifying the file created in step 2 as input. 
This step insures that the crontab file created in step 2 will be scanned by cron 
every minute. After invoking this command, the step 2 file will be stored in the 
file: 

/usr/spool/cron/crontabs/adm 

4. At this point, you are finished creating crontab entries. If you ever want to change 
the entries, simply re-edit the file created in step 2 and use the crontab (1) command 
again. 

The following entries, accompanied by a description of each, should be made in the 
crontab file created in step 2: 

• 0 4 * * 1-6 /usr/lib/acct/runacct 2> /usr/adin/acct/nite/fd21og 

runacct, the main accounting shell script, should be executed daily (during non¬ 
prime hours) to generate daily accounting reports. The above entry executes 
runacct at 4:00am every Monday through Saturday. Error messages will be redi¬ 
rected to the file /usr/adin/acct/nite/fd21og, if any errors occur while runacct 
executes. 

• 0 2 * * 4 /usr/lib/acct/dodisk 

dodisk creates total accounting records that summarize disk space usage for indi¬ 
vidual users. This entry runs dodisk at 2:00am every Thursday morning. 

• 5 * * ♦ ♦ /usr/lib/acct/ckpacct 

To insure that the process accounting file, pacct, doesn’t get too large, the command 
ckpacct should be executed hourly. This entry invokes ckpacct at five minutes into 
every hour. 

• 15 5 1 * * /usr/lib/acct/monacct 
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The monthly merging of accounting data is facilitated through the monacct com¬ 
mand. This entry allows monacct to generate a monthly total report and total 
accounting file, monacct will be executed at 5:15am on the first day of every month. 


Note 

The dates and times shown in the crontab entries above are only 
suggestions; you can tailor crontab entries to suit your needs. How¬ 
ever, if you use different entries than those shown here, be sure that 
monacct is run at such a time as to allow runacct sufficient time to 
finish. 


Setting PATH for Accounting Commands 

Finally, you should set the PATH shell variable in /usr/adm/.profile so that System 

Accounting knows where to look for commands. Path should be set as follows: 

PATH=/usr/lib/acct:/bin:/usr/bin:/etc:/usr/adm 

Summary of Daily Operation 

The daily operation of System Accounting is summarized by the following steps: 

1. When HP-UX is switched into multi-user mode, the system initialization shell script 
rc executes the accounting command startup. The purpose of startup is to start 
Accounting, and it performs the following functions: 

a. Calls acctwtmp to add a boot record to wtmp. This record is marked by storing 
“acctg on” in the device name field of the wtmp record. 

b. Turns process accounting on via turnacct on. turnacct on executes accton 
with the filename argument /usr/adm/pacct. 

c. It removes work files left in the sum directory by runacct. 

2. A report of the previous day’s accounting information can be created by running 
prdaily. Obviously, this step is omitted the first day that Accounting is installed, 
because the previous day’s accounting information doesn’t yet exist. However, after 
riinacct has been executed, prdaily will generate valid reports. 
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3. The ckpacct command is executed every hour via cron to insure that the process 
accounting file pacct doesn’t become too large. If pacct grows past a set maxi= 
mum number of blocks, turnacct switch is invoked, which creates a new pacct file. 
(Other conditions may also limit the size of the process accounting file or turn pro¬ 
cess accounting off; for more details, see the discussion of ckpacct in the “Process 
Accounting” section.) The advantage of having several smaller pacct files is that 
runacct can be restarted faster if a failure occurs while processing these records. 

4. The chargefee program can be used to charge fees to users. It adds records to 
the file fee. These records are processed during the next execution of runacct and 
merged in with total accounting records. 

5. runacct is executed via cron each night. It processes the active fee file and the 
process, connect session, and disk total accounting files. It produces command and 
resource-usage summaries by login name. 

6. When the system is turned off using shutdown, the shutacct command is executed. 
The purpose of shutacct is to stop Accounting, and it performs the following func¬ 
tions: 

a. Writes a termination record to wtmp via the command acctwtmp. This record 
is marked by having “acctg off” in the device name field. 

b. Turns process accounting off by calling turnacct off. 


Overview of System Accounting 

In this section, the intrinsics of System Accounting are examined. Key terms are defined, 
commands are introduced, system data flow is described, and finally, you are shown the 
login and directory structure of System Accounting. 
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Definitions 

The following terms are used often in System Accounting; understanding these definitions 
is essential to successfully using accounting capabilities. Additional HP-UX terms are in 
the Glossary. 

connect session 

This denotes the period of time in which a user is connected to the system. It starts 
when the user logs in and finishes when the user logs out. 

prime/non-prime connect time 

Prime time is the time during the day when the computer system is most heavily used— 
for example, from 9:00am to 5:00pm. Non-prime time is the remaining time during the 
day when the system is less heavily used—from 5:00pm to 9:00am in this example. 

When reporting computer time usage, System Accounting distinguishes between prime 
and non-prime time usage. You can specify prime and non-prime time on your system by 
editing the file /usr/lib/acct/holidays. (For details on the holidays file, see the section 
“Updating the Holidays File” in this chapter. 


Note 

Prime time is in effect only on weekdays (Monday through Friday); 
non-prime time is in effect during the weekends (Saturdays and 
Sundays) and on any holidays specified in the holidays file. 


process accounting records 

Once System Accounting is installed and turned on, the following occurs: whenever a 
process terminates, the kernel writes a process accounting record for the terminating 
process into the current process accounting file, /usr/adm/pacct by default (you can 
specify that a file other than pacct be used as the process accounting file, if you want). 
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A process accounting record contains resource-usage data for a single process; it summa¬ 
rizes how much of the various resources the process used during its lifetime. Examples 
of information contained in process accounting records are: 

• the user ID of the process’s owner 

• the name of the command that spawned the process 

• the amount of time it took the process to execute 

For greater detail on the contents and format of process accounting records, see acct(5) 
in the HP-UX Reference Manual. 

total accounting records 

These records, created by various accounting commands, contain summary accounting 
information for individual users. These records provide the basic information for many 
reports generated by System Accounting. Some examples of information contained in 
these records are: 

• the ID and user name of the user for whom the total accounting record was created 

• the total number of processes that the user has spawned during the accounting 
period for which the total accounting record was created 

• fees for special services rendered to this user 

The exact contents and format of total accounting records can be found in acct(5). In 
addition, commands covered in later sections of this chapter show how these records are 
created and used by System Accounting. 
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Introduction to Commands 

System Accounting provides many versatile commands to accomplish numerous varied 
tasks. There are commands that create data, commands that display data, commands 
that remove data, commands that merge data, and commands that summarize and report 
data. In addition, the output of one command may be the input to others, and so on. 

Accounting commands can be logically categorized into six basic command groups: 

• installation 

• disk usage accounting 

• connect session accounting 

• process accounting 

• fee charging 

• summarizing and reporting accounting information 

Descriptions of these command groups, along with a brief synopsis of each command, 
follow: 

Installation 

These commands insure that System Accounting is properly installed. They are used to 
turn accounting on when HP-UX is powered up and turn accounting off when the system 
is shut down. They may also do some file cleanups. Two such commands exist: 

• startup —starts accounting when HP-UX is switched to multi-user mode. Invoked 
from /etc/rc. 

• shutacct turns off accounting when HP-UX is turned off via the /etc/shutdown 
shell. 
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Disk Usage Accounting 

In general, these commands produce disk usage accounting information: they show disk 
space usage (in blocks) for individual iisers. They also produce total accounting records. 
There are four commands: 

• acctdusg and diskusg —both commands show how many blocks of disk space users 
are consuming. They differ in command options, and the manner in which they 
produce the information— acctdusg takes its input from a list of path names created 
by find, and diskusg looks at the inodes of the file system to create its output. 

• acctdisk —this command produces total accounting records. Its input is supplied 
(either directly or indirectly) from acctdusg or diskusg. 

• dodisk —Produces total accounting records by using the diskusg and acctdisk com¬ 
mands. dodisk is normally invoked by cron. 

Connect Session Accounting 

Independently of System Accounting, the programs login and init record connect ses¬ 
sions by writing records into /etc/wtmp. Accounting commands can display or fix this 
file, and can produce total accounting records for this file. There are five commands: 

• fwtmp —displays the information contained in wtmp. 

• wtmpfix —normalizes connect session records that span date changes (see date(l)). 
Also validates login names in connect session records. 

• acctconl —summarizes wtmp in ASCII readable format, producing one line per con¬ 
nect session. 

• acctcon2 —takes input of the format produced by acctconl and produces total ac¬ 
counting records as output. 

• prctmp —used to display the session record file. (The session record file is normally 
/usr/adm/acct/nite/ctmp.) 
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Process Accounting 

When process accounting is turned on, the kernel writes a process accounting record 
to pacct whenever a process terminates. A number of accounting commands exist that 
summarize and report this accounting information. In addition, certain commands turn 
process accounting on or off and insure that pacct doesn’t become too large. There are 
eight process accounting commands in all: 

• accton— turns process accounting on or off, depending on whether or not a filename 
argument is supplied with the command. If no filename is given, then process 
accounting is turned off; the kernel stops writing process accounting records to 
pacct. If a filename is specified, then the kernel starts writing process accounting 
records to the specified filename. 

accton uses the system call acct (2) to turn process accounting on or off. In addition, 
only the super-user can execute accton. 

• ckpacct —checks the size of the process accounting file pacct. If pacct becomes 
too large, then a new pacct file is created via turnacct switch. If disk space be¬ 
comes critically short, then process accounting is turned off until sufficient space 
is available. This command is normally invoked by cron. 

• turnacct on I off I switch —performs one of three functions, depending on which 
argument (on, off, or switch) is specified, turnacct on turns process accounting on 
by calling accton with the default filename argument /usr/adm/pacct; turnacct off 
turns process accounting off by calling accton with no filename argument; turnacct 
switch renames the current pacct file (so that it is no longer the current process 
accounting file) and creates a new, empty pacct file. 

• acctcom —displays process accounting records contained in pacct (or any specified 
file). 

• acctcms takes pacct as input, and produces summary accounting information by 
command, as opposed to by process. 

• acctprcl produces readable process accounting information, mainly for input into 
acctprc2. 

• acctprc2 takes input of the form produced by acctprcl and produces total ac¬ 
counting records. 
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Charging Fees 

Occasionally, you may want to charge a user for something. For example, you might 
charge fees to users for fixing any damaged files that they have. The chargef ee command 
allows you to charge fees to specific users. 

Summarizing and Reporting Accounting information 

This group of commands summarizes and reports the data created through the command 
groups described above. These are the commands that are probably used most frequently; 
they represent the highest level of accounting commands. Five such commands exist: 

• prtacct —takes as input total accounting records and displays the records in ASCII 
readable format. 

• acctmerg— combines the contents of separate total accounting files into a single 
total accounting file. Allows the merging of disk, process, and connect session total 
accounting records. 

• runacct —the main accounting shell script. Normally invoked daily by cron, this 
command processes disk, connect session, process, and fee accounting information 
and produces summary files and reports. It accomplishes its task by proceeding 
through various run-levels. In each successive run-level it invokes accounting com¬ 
mands to perform a specific task. For example, in one run-level, total accounting 
records for connect sessions are created; in another, disk, connect session, process, 
and fee total accounting records are merged to create one total accounting file. 

• prdaily —invoked by runacct to format a report of the previous day’s accounting 
data; the report is stored in the file /usr/adm/acct/sum/rptrnrndd where mmdd is 
the month and day of the report, runacct may also be used to display a report of 
the current day’s accounting information. 

• monacct —invoked once a month (or accounting period), this command summarizes 
daily accounting files and produces a summary files for the accounting period. 
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System Data Flow 

At this point, you have the rudimentary knowledge necessary to understand how System 
Accounting works; you know some important definitions and should basically know what 
the various commands do. The purpose of this section is to help you visualize how the 
different commands work together to create accounting data. 

Figure 6-1 illustrates how accounting data is created. The diagram is broken into five 
separate sub-diagrams, each one representing the data flow for a given command group. 
The following notational conventions are used: 


Symbol 

source => dest 


cause ^ object 


files 


Description 

Wide arrows represent the transfer of data from a source to a desti¬ 
nation. The source is at the start of the arrow; the destination, at 
the point. For example, the inodes of the file system are the source 
of information used by diskusg, which in turn is the source of disk 
usage reports that are inputs to acctdisk. 

Thin arrows represent cause-effect relationships. The cause lies at 
the start of the arrow; the object affected lies at the point. For 
example, turnacct on invokes accton which then signals the kernel 
to begin writing process accounting records to pacct. 

Boxes with rounded corners represent files or groups of files. In a 
more general sense, they represent the inputs to and outputs from 
the various commands. 


Note 

The installation commands do not appear in the diagram, because 
they aren’t directly involved in the data creation process; they 
merely insure that it happens. 


Note 

The commands runacct and prdaily are shown as having no inputs. 
This isn’t exactly true: they do have inputs, but they get their 
inputs by executing other accounting commands. In essence, their 
inputs are the same basic inputs of the other command groups. 
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Disk Usage Accounting 
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Figure 6-1. System Accounting Data Flow Diagram 
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Figure 6-1. System Accounting Data Flow Diagram (con’t) 

Login and Directory Structure 

You now know the basics, but you still can’t begin learning the day-to-day usage of 
accounting commands until you know where to log in. In addition, you should know the 
accounting directory structure- where the various commands, directories, and files are 
located. These two topics are discussed here. 

Logging in 

The login name for System Accounting is adm; the user ID for adm is 4. The adm login is 
a member of the group adm, and the group adm has a group ID of 4, also. 

The home directory for the adm login is /usr/adm. You log in to System Accounting the 
same way you do for any account—simply supply the login name to the HP-UX login 
prompt: 

login: adm 


Note 

The integrity of accounting data files must be maintained if System 
Accounting is to generate accurate reports. For this reason, it is 
highly recommended that a password be used with the adm login. 
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Directory Structure 

System Accounting uses a multi-level directory structure to organize its many accounting 
files. Each directory in this structure stores related groups of files, commands, or other 
directories. (See the section “System Accounting Files” for definitions of the accounting 
data files.) 

Figure 6-2 illustrates this structure, and descriptions of each director}^ follow: 

• /usr/adm —contains all active data-collection files, such as pacct and fee. 

• /usr/adm/acct -contains the nite, sum, and fiscal directories described below. 

• /usr/adm/acct/nite —stores data files that are processed daily by runacct. 

• /usr/adm/acct/sum —cumulative summary files updated by runacct are kept here. 

• /usr/adm/acct/fiscal —periodic (monthly) summary files created by monacct are 
found here. 

• /usr/lib/acct —System Accounting commands reside here. 

• /etc contains wtmp, and shell scripts rc and shutdown. 
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Figure 6-2. System Accounting Directory Structure 
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Disk Space Usage Accounting 

System Accounting provides the means to monitor disk space utilization for individual 
users. In this section, disk space usage accounting commands are explained. Before read¬ 
ing this discussion, you may want to review the “File System Implementation” section 
of the “Concepts” chapter. 

Disk usage commands provide two main functions: they report disk usage (in blocks) for 
individual users and create disk total accounting records (supplied as inputs to commands 
such as prtacct or runacct). 

Reporting Disk Space Usage 

Two commands— acctdusg and diskusg- report disk usage for individual users; both 
commands show the number of disk blocks allocated to specific users. However, each 
command has slightly different options. In addition, each differs in the manner in which 
it produces accounting information. 

acctdusg 

acctdusg takes from standard input a list of path names, usually created by the find 
command. For each file in the list, acctdusg identifies the owner of the file, computes the 
number of blocks allocated to the file, and adds this amount to a running total for the 
file’s owner. When finished looking through the list, acctdusg displays the information 
accumulated for each user: user ID, user name, and number of blocks used. 

This command is useful for reporting disk usage information for specific users or files. 
For example, suppose you want to know how many blocks of disk space you are using: 
your user ID is 351, user name is bill, and your home directory is /users/pseudo/bill. 
The following illustrates how you would use the find and acctdusg commands to show 
this information. 

$ find /users/pseudo/bill -print > bills.files 
$ acctdusg < bills.files 
00351 bill 30 

$ rm bills.files 

In the above example, bill is using 30 blocks of disk space. The series of commands 
shown could easily have been combined into one line, such as: 

$ find $H0ME -print I acctdusg 
00351 bill 30 
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The next example shows how to use acctdusg to generate disk usage information for all 
files in the system: 


$ find / -print i 

1 acctdusg 

00350 

fred 

11 

00351 

bill 

30 

00352 

mike 

17 

00353 

sarah 

13 

00354 

molly 

18 

00000 

root 

3 

00004 

adm 

36 

00001 

bin 

2434 


Two options are included with acctdusg: 

-u no_owners If -u is given, then path names of the files for which no owner is found 
are written into the file no_owners. This option could potentially find 
users who are trying to avoid disk charges. 

-p p_file The password file /etc/passwd is the default file used by acctdusg to 

determine ownership of files. If the -p option is used, then acctdusg 
will use p^file instead. This option is not needed if your password file 
is /etc/passwd. 

The shell script grpdusg provided in the section called ‘‘Sample Accounting Shell Scripts” 
displays disk accounting information for users in a given group. It illustrates the use of 
the -u option with acctdusg. 

diskusg 

This command reports disk usage information in the same format as acctdusg user 
ID, user name, and total disk blocks used. However, diskusg generates disk accounting 
information by looking through the inodes of a specified special file (sec inode(5) and 
the “File System” section of the “Concepts” chapter for more information on inodes and 
special files.) Therefore, diskusg is faster and more accurate than acctdusg. 

The syntax of the diskusg command is: 
diskusg [option^ [Jiles[ 

It generates a disk usage report from data in files, if specified; otherwise standard input 
is used, diskusg is normally invoked with the files argument. When specified, files are 
the special filenames of the devices containing the inode information used by diskusg to 
generate its report, files is normally a special file from the /dev directory. 
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The following options may be used with diskusg: 


-s This tells disloisg that: (1) input is in diskusg output format, and (2) that 

all lines for a single user should be combined into a single line. This option 
is used to merge data from separate files, each containing the output from 
using diskusg on different devices. 

-V This option is useful for finding users who are trying to avoid disk space 

accounting charges. When this option is specified, diskusg writes records to 
stderr (standard error output) showing the special file name, inode number, 
and user ID of files that apparently have no owner. 


-i fnmlist Causes diskusg to ignore the data on those file systems whose file system 
name is in fnmlist fnmlist is a list of file systems separated by commas or 
enclosed within quotes. 


-p p_file This is the same as the -p option of acctdusg. 

-u u^file This option produces exactly the same output as the -v option. The dif¬ 
ference between the two options is that -v writes its output to stderr; this 
option writes its output to the file u_file. 


The output of diskusg is normally used by acetdisk to create disk total accounting 
records. In addition, diskusg is normally called by dodisk. 

The following example creates disk usage information for all users whose files reside on 
the disk whose device file is /dev/rdsk/OsO. Note that the file system used in this example 
is the same as was used in the previous acctdusg example. 

$ diskusg /dev/rdsk/OsO 


0 

root 

10616 

1 

bin 

778 

4 

adm 

96 

350 

fred 

14 

351 

bill 

32 

352 

mike 

20 

353 

sarah 

16 

354 

molly 

22 

355 

horatio 

2 

501 

guest 

2 
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The differences between diskusg and acctdusg are best illustrated by comparing their 
outputs. Note that: 

1. acctdusg places leading zeros on user IDs; diskusg doesn’t. 

2. acctdusg counts files only under each users $HOME directory. Files that users 
own in directories other than their home directory (for example, files in the /tmp 
directory) are counted as files with no owner. 

3. Two extra users horatio and guest —show up in the output of diskusg when com¬ 
pared with the output from 

find / -print 1 acctdusg 

This occurred because the directories of these two users were empty; therefore, no 
disk usage totals were generated. However, diskusg looked at inodes and saw' that 
horatio and guest were actually using two blocks for the directories themselves. 

4. If two or more users have links to a particular file, then acctdusg will prorate disk 
space usage for the file between each user. For example, if three users had a link 
to a 300-block file called skurbnich.dat, each user would be charged for 100 blocks 
of this file. 

Creating Total Accounting Records 

Two commands are used to create total accounting records: acctdisk, and dodisk. 

acctdisk 

acctdisk takes from standard input records of the format produced by acctdusg and 
diskusg. From these records, acctdisk produces disk total accounting records that may 
be inputs to prtacct or runacct. 

The following would write disk total accounting records to the file disktacct for all users 
in the group pseudo: 

find / -group pseudo -print I acctdusg I acctdisk > disktacct 

The next example would generate disk total accounting records for all users who have 
files on the disk rhd. The total accounting records are written to the file disktacct. 

diskusg /dev/rdsk/OsO I acctdisk > disktacct 
acctdisk has no options and is normally invoked by dodisk. 
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dodisk 

dodisk is normally invoked by cron to create disk total accounting records for daily usage 
by System Accounting- The syntax for dodisk is: 

dodisk [- 0 ] [ files ... ] 

In the default case, dodisk creates disk total accounting records on the special files 
whose names are stored in /etc/checklist: the special file names are supplied as input 
to diskusg, which pipes its output to acctdisk, which in turn creates total accounting 
records. 

If the “O option is used, dodisk creates total accounting records more slowly by using 
acctdusg instead of diskusg. 

If files are used, disk accounting will be done on these file systems only. If the -o option is 
used, then files should be mount points of mounted file systems; if omitted, they should 
be the special file names of mountable filesystems. 


Note 

See the “Daily Usage and Installation” section of this chapter for 
more information on how dodisk should be invoked by cron. 
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Connect Session Accounting 

Whenever a user logs in or out of HP-UX, the program login records the connect session 
in the file /etc/wtmp. Records in wtmp contain the following information: 

• the terminal name on which the connect session occurred, 

• the login name of the user, 

• the current time/date at login or logout, and 

• other status information (see utmp(5) for details). 

System Accounting provides commands that allow you to write records to wtmp, to display 
and manipulate wtmp, and to create total accounting records from wtmp. These commands 
are covered in this section. 

Writing Records to wtmp - acctwtmp 

The command acctwtmp allows you to write records to wtmp for whatever rea.son you 
might have, acctwtmp is normally invoked by startup and shutacct to record when 
System Accounting was turned on and off respectively. The format of the command is: 

acctwtmp ‘‘reason” 

where reason is string describing the reason for writing the record to wtmp. Note that 
acctwtmp does not directly write records to wtmp: it writes a record containing the terminal 
name, current time, and reason string to standard output. To actually write the record 
to wtmp you must append the output from acctwtmp to the wtmp file as follows: 

acctwtmp “reason” >> /etc/wtmp 

The reason string may be any combination of letters, numbers, spaces, and the dollar 
sign ($), but may not exceed 11 characters in length, (reason must be enclosed in double 
quotes as shown.) 
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Displaying Connect Session Records - fwtmp 

To display the contents of wtmp, you can use the command fwtmp. When no options are 
used, f wtmp takes from standard input records of the format contained in wtmp; it writes 
to standard output the ASCII readable equivalent of the input records. The output of 
this command can either: 

1. be edited, via a HP-UX editor such as vi, and then rewritten to wtmp using special 
fwtmp options described below; or 

2. supplied as input to commands which convert the information to total accounting 
records. 

The syntax of fwtmp is: 
fwtmp [-zc] 

The options can be used in any combination. The following table describes what the 
different combinations do. 

Option Description 

-ic Denotes that input is in ASCII readable form and is to be converted to binary 

form. This is essentially the opposite of using fwtmp without any options. 

-i Both input and output are in ASCII readable format. This is the same as 

performing an ASCII to ASCII copy. 

-c Both input and output are in binary format—a binary to binary copy. 
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The following example shows the output produced by fwtmp and is followed by descrip¬ 
tions of each column in the report: 

$ fwtmp < /etc/wtmp 



system boot 

0 

2 

0000 

0000 

479472540 

Mar 

12 

03:49:00 

1985 

root 

CO console 

0 

7 

0000 

0000 

479475173 

Mar 

12 

04:32:53 

1985 


acctg on 

0 

9 

0000 

0000 

479493135 

Mar 

12 

09:32:15 

1985 

mike 

al ttyal 

352 

7 

0000 

0000 

479493590 

Mar 

12 

09:40:00 

1985 

mike 

al ttyal 

352 

8 

0011 

0000 

479496000 

Mar 

12 

10:20:00 

1985 

sarah 

07 tty07 

353 

7 

0000 

0000 

479518335 

Mar 

12 

16:32:15 

1985 

bill 

10 ttylO 

351 

7 

0000 

0000 

479521475 

Mar 

12 

17:24:35 

1985 

sarah 

07 tty07 

353 

8 

0011 

0000 

479522478 

Mar 

12 

17:41:18 

1985 

bill 

10 ttylO 

351 

8 

0011 

0000 

479526487 

Mar 

12 

18:48:07 

1985 


CO console 

0 

8 

0011 

0000 

479526488 

Mar 

12 

18:48:08 

1985 


acctg off 

0 

9 

0000 

0000 

479526493 

Mar 

12 

18:48:13 

1985 


system boot 

0 

2 

0000 

0000 

479389800 

Mar 

12 

05:00:00 

1985 


Column Description 

1 The login name of the user who logged in or out. 

2 /etc/inittab id (this is usually the number of the line on which the connect 
session took place). 

3 The name of the device on which the connect session occurred. 

4 Process id of the user who logged in or out. 

5 Entry type. This field contains information on the type of record—for ex¬ 
ample, it shows whether the record is a login record (entry type=7), lo¬ 
gout record (entry type=8), or if the record was written by acctwtmp (entry 
type=9). See utmp(5) for more details on this field. 

6—7 Exit status for connect session. See login(l) and utmp(5) for details. 

8 Time that entry was made (in elapsed seconds since January 1, 1970). 

9—12 The equivalent of column 8 in date/time format showing month, day, time 

of day (in 24-hour format), and year. 
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Fixing wtmp Errors - wtmpfix 

When a user logs into HP-UX, the login program stores the value seven (7) in the entry 
type held of the connect session record. When the same user logs out, an entry type 
of eight (8) is recorded. You can see this by examining the sample output created by 
fwtmp in the previous section. Note that in the example, login records precede their 
corresponding logout records in chronological order. 

Occasionally, this time-stamped ordering becomes inconsistent: logout records might 
precede login records. (This occurs when the date and time are reset while users are 
still logged in.) When this happens, the commands that create connect session total 
accounting records will not work properly. 

Fortunately, there is a command that fixes corrupted wtmp files: wtmpfix. wtmpfix takes 
as input wtmp binary records and corrects the time/date stamps to be consistent; its 
standard output is also binary wtmp records. Its syntax is: 

wtmpfix [files] 

If files is given, then input is taken from files. A dash (-) can be used in place of files to 
indicate standard input. Note that if you specify wtmp as both input to and output from 
this command, wtmp will be destroyed. Therefore, take care not to destroy wtmp. The 
following shows how to properly fix wtmp using wtmpfix: 

$ wtmpfix /etc/wtmp > wtmp.temp 
$ fwtmp -c < wtmp.temp > /etc/wtmp 
$ rm wtmp.temp 

Creating Total Accounting Records 

This final set of connect session accounting commands is used to create connect session 
total accounting records. Before reading any further, you may want to review Figure 6-1 
(in the “System Data Flow” section). 

acctconi 

acctconl converts a sequence of login/logoff records (of the format contained in wtmp) 
read from its standard input to a sequence of records, one per login session. Its input 
is normally redirected from wtmp; its output is columnar ASCII and can be supplied as 
input to prctmp or acctcon2. 
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The use of acctconl is illustrated below by first displaying the contents of wtmp with 
fwtmp and then using acctconl to create connect session summary file. The columnar 
data produced by acctconl is described after the report. 

$ fwtmp < /etc/wtmp 




system boot 

0 

2 

0000 

0000 

479472540 

Mar 

12 

03:49:00 

1985 

root 

CO 

console 

0 

7 

0000 

0000 

479475173 

Mar 

12 

04:32:53 

1985 



acctg on 

0 

9 

0000 

0000 

479493135 

Mar 

12 

09:32:15 

1985 

mike 

al 

ttyal 

352 

7 

0000 

0000 

479493590 

Mar 

12 

09:40:00 

1985 

mike 

al 

ttyal 

352 

8 

0011 

0000 

479496000 

Mar 

12 

10:20:00 

1985 

sarah 

07 

tty07 

353 

7 

0000 

0000 

479518335 

Mar 

12 

16:32:15 

1985 

bill 

10 

ttylO 

351 

7 

0000 

0000 

479521475 

Mar 

12 

17:24:35 

1985 

sarah 

07 

tty07 

353 

8 

0011 

0000 

479522478 

Mar 

12 

17:41:18 

1985 

bill 

10 

ttylO 

351 

8 

0011 

0000 

479526487 

Mar 

12 

18:48:07 

1985 


CO 

console 

0 

8 

0011 

0000 

479526488 

Mar 

12 

18:48:08 

1985 



acctg off 

0 

9 

0000 

0000 

479526493 

Mar 

12 

18:48:13 

1985 

$ acctconl 

< 

/etc/wtmp 










520095488 


353 sarah 

1665 

2478 479518335 Tue Mar 

12 16:32 

15 1985 

521012224 


352 mike 




479493590 Tue Mar 

12 09:40 

00 1985 

520095488 


351 bill 

0 


5012 479521475 Tue Mar 

12 17:24 

35 1985 

521011712 


0 root 

41047 

6488 479475173 Tue Mar 

12 04:32 

53 1985 


Descriptions of the columnar data produced by acctconl follow: 


Column Description 

1 Shows the device address (in decimal equivalent of major/minor device ad¬ 
dress) at which the connect session occurred. 

2 Gives the user ID for the connect session record. 

3 Displays the login name for the user. 

4 Shows the number of prime connect time seconds that were used during the 
connect session. 

5 Shows non-prime connect seconds. 

6 The connect session starting time (in seconds elapsed since January 1, 1970) 
is displayed here. 

7-11 The remaining columns convert column six to date/time format. 
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In addition to its normal usage, acctconl has four options: 

Option Description 

-p This option tells acctconl not to produce one record per connect session. 

Instead, acctconl simply echoes its input—one line per wtmp record—showing 
line name, login name, and time (in both seconds and day/time format). 
Using this option is similar to using fwtmp, except that this option doesn't 
show status information, whereas fwtmp does. 

-t acctconl maintains a list of lines on which users are logged in. When it 

reaches the end of its input, it emits a session record for each line that still 
appears to be active. It normally assumes that its input is a current file, so 
that it uses the current time as the ending time for each session in progress. 
The -t flag causes it to use, instead, the last time found in its input, thus 
assuring reasonable and repeatable numbers for noncurrent files. 

“1 file This option causes a line usage summary report to be placed in file. This 
report shows each line’s name, number of minutes used, percentage of total 
elapsed time used, number of sessions charged, number of logins, and number 
of logins and logoffs. This report can be used to keep track of line usage, 
identify bad lines, and find software/hardware oddities. Note that hang-up, 
termination of login, and termination of the login shell each generate logoff 
records; therefore, the number of logoffs is often three to four times the 
number of connect sessions. 

Shown below is an example of the line use file (line_use) created from the 
same wtmp file used in the previous acctconl example; the standard output of 
acctconl has been redirected into the file ctmp. 

-o file Using the -o option (e.g., acctconl -o f .overall) causes file to be filled with 
an overall record for the accounting period, giving starting time, ending time, 
number of reboots, and number of date changes. 


$ acctconl -t -1 line.use < /etc/wtmp > ctmp 
$ cat line.use 

TOTAL DURATION IS 899 MINUTES 


LINE 

MINUTES 

PERCENT 

# SESS 

# ON 

# OFF 

console 

856 

95 

1 

1 

1 

tty07 

69 

8 

1 

1 

1 

ttyal 

40 

4 

1 

1 

1 

ttylO 

84 

9 

1 

1 

1 

TOTALS 

1049 

-- 

4 

4 

4 
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prctmp 

The prctmp command is simple. Its only function is to put headings on the output created 
by acctconl: prctmp makes a readable report from the output of acctconl. 

prctmp takes its input from standard input; therefore, to create a prctmp report from 
acctconl information, you can simply pipe the output from acctconl into prctmp as 
follows: 

$ acctconl < /etc/wtmp I prctmp 

prctmp will respond by generating a report with appropriate headings over the columns 
of output from acctconl. 

acctcon2 

acctcon2 creates connect session total accounting records from standard input of the 
format created by acctconl. In other words, to create connect session total accounting 
records, simply send the output from acctconl into the input of acctcon2. 

The total accounting records created by acctcon2 are sent to standard output. So if you 
want to store these records, you must redirect standard output. The following command 
line shows how to write total accounting records from the connect session record file 
(wtmp) into the file ctacct: 

$ acctconl < /etc/wtmp I acctcon2 > ctacct 
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Process Accounting 

Process accounting coniinanus provide the means to accumulate execution statistics— 
such as memory usage, CPU time, number of input/output transfers—for individual 
processes. This section describes how to: 

1. Turn process accounting on, 

2. Turn process accounting off, 

3. Make sure that the process accounting file (pacct) doesn't become too large, 

4. Display process accounting records, 

5. Generate a command summary report, and 

6. Create total accounting records from the process accounting file. 

You might find it helpful to look at the System Data Flow Diagram (Figure 6-1) when 
reading this section. 

Turning Process Accounting On 

Before System Accounting can generate process accounting data, process accounting 
must be turned on; two commands can be used to accomplish this task: turnacct on 
and accton. After process accounting has been turned on, the kernel will write a process 
accounting record, for every terminating process, into the current process accounting file 
(pacct by default). 


Note 

The startup command, placed in the system initialization shell 
script /etc/rc, automatically turns process accounting on. There¬ 
fore, if you have updated /etc/rc for System Accounting (as de¬ 
scribed in the section “How to Install System Accounting”), pro¬ 
cess accounting will automatically be activated, and you should 
seldom need to use the commands described here. 

These commands are described only for your benefit should you 
ever need to manually turn process accounting on or off 
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turnacct on 

The command used most often to activate accounting is turnacct on; only the super- 
user and the adm login can execute this command, turnacct on assumes that the process 
accounting file is the default file pacct. The action of turnacct on can be summarized as 
follows: 

1. Check to see if the process accounting file pacct exists. 

2. If pacct doesn’t exist, then create a new pacct file. 

3. Turn process accounting on by invoking accton with the filename argument pacct. 

To execute this command, simply enter turnacct on to the HP-UX prompt. Note that 
only the adm login and the super-user can execute this command. 

accton 

Again, only the super-user and the adm login can execute accton. When invoked with a 
filename argument, accton turns on process accounting and makes the specified filename 
the current process accounting file. For example, 

$ accton /usr/adm/pacct 

tells the kernel to start writing process accounting records to the file /usr/adm/pacct. The 
next example would activate process accounting and make the current process accounting 
file /usr/adm/XX107: 

$ accton /usr/adm/XX107 


note 

You must make sure that the filename you specify is an existing 
file; otherwise, accton will fail. 


Note that in the System Data Flow Diagram (Figure 6-1), accton is shown calling another 
routine, acct. acct is the system call that actually tells the kernel to start writing process 
accounting records. See the HP-UX Reference for more details on acct. 


294 System Accounting 


Turning Process Accounting Off 

Two commands are used to turn process accounting off: turnacct off and accton (with 
no filename argument). These commands tell the kernel to stop writing records to the 
current process accounting file. 


note 

If you have updated the /etc/shutdovm shell script as described 
in the section '‘How to Install System Accounting,” you may sel¬ 
dom ever use these commands. The reason is that the shutacct 
command, added to /etc/shutdown, automatically turns process 
accounting off. 


turnacct off 

turnacct off can be executed by only the super-user and the adm login, turnacct off 
turns process accounting off by invoking the accton command without the optional file¬ 
name argument. You execute this command by typing: 

$ turnacct off 

accton 

When accton is invoked without the optional filename argument, process accounting is 
turned off. You would enter this command as: 

$ accton 

As shown in the System Data Flow Diagram (Figure 6-1), accton tells the kernel to stop 
writing process accounting records by using the system call acct. 
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Checking the Size of pacct 

On a multi-user system, many processes can execute during a single hour. Therefore, 
process accounting files have the potential to become quite large. System Accounting 
has built-in mechanisms that insure that the default process accounting file pacct doesn’t 
become too large. The two commands used for this purpose are: turnacct switch and 
ckpacct. 


note 

The commands described here work only on the default process 
accounting file, pacct. 


ckpacct 

The command ckpacct is normally invoked by cron every hour to insure that the current 
process accounting file pacct hasn’t become to large. The format of ckpacct is: 

ckpacct [blocks] 

If the size of pacct exceeds the blocks argument, 1 000 by default if blocks is not specified, 
then turnacct switch is executed, which renames the current pacct file and creates a new 
pacct file. 


Note 

If the number of free blocks in the /usr file system falls below 500, 
ckpacct will automatically turn off process accounting via turnacct 
off. When at least 500 blocks become available, process accounting 
will be reactivated. 

The kernel may also enforce a size limit on the size of pacct. This 
will take precedence over the limit set by ckpacct. See acctsh(lM) 
and acct(2) in the HP-UX Reference Manual for more details. 
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turnacct switch 

turnacct switch is used to create a new pacct file when the current pacct file is too large. 
The action of turnacct switch can be summarized as follows: 

1. Process accounting is temporarily turned off. 

2. The current pacct file is renamed to pacctincr, where incr is a number starting at 1 
and incrementing by one for each additional pacct file that is created via turnacct 
switch. 

3. Since the old pacct file was renamed to pacctincr, a new, current pacct file is 
created. 

4. Process accounting is restarted; the kernel starts writing records to the newly cre¬ 
ated pacct file. 

The example below illustrates the effect of using the turnacct switch command. In the 
example, turnacct switch is executed from the adm home directory /usr/adm. Comment 
lines begin with a cross-hatch(#) and are included in the example only as explanatory 
material. 

$ # 

$ # First, list all the process accounting files 
$ # (at this point, there is only one). 

$ # 

$ 11 pacct* 

-rw-rw-r-- 1 adm adm 2196 Mar 21 12:44 pacct 

$ # 

$ # Now execute turnacct switch, which will rename the current 
$ # pacct file to pacctl and will create a new pacct file. 

$ # 

$ turnacct switch 

$ # 

$ # Now verify this by listing all process accounting 
$ # files again. 

$ # 

$ 11 pacct* 

-rw-rw-r-- 1 adm adm 72 Mar 21 12:46 pacct 

-rw-rw-r— 1 adm adm 2196 Mar 21 12:44 pacctl 

$ # 

$ # The current process accounting file is pacct. The previous 
$ # process accounting file is now named pacctl. 

$ # 
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Displaying Process Accounting Records - acctcom 

The acctcom command allows you to display records from any file containing process 
accounting records. Normally you would use this command to display records from the 
pacct files (pacct, pacctl, pacct2 ...). 

acctcom is a very versatile command; its syntax follows: 
acctcom [[options][file]] ... 

If no file is specified, acctcom uses the current pacct file as input. Input can also be taken 
from standard input. Some of acctcorn’s options allow you to select only the records that 
you want to see; other options control the format of the report. 

The information contained in this section is organized as follows: 

• First, definitions are given for the columnar data produced by acctcom. 

• Command options that control the format of the report are discussed. 

• Options that allow you to select particular records are described. 

• Finally, to help you understand how to use acctcom’s options, sample acctcom re¬ 
ports are shown. 

Definitions of Information Produced by acctcom 

acctcom generates a columnar report with descriptive headings on each column. Each line 
of the report represents the execution statistics that a particular process accumulated 
during its lifetime. The following table defines the standard columns in the report—i.e., 
the columns that are displayed when none of acctcom’s options are specified. 

Column Header Definition 

COMMAND NAME The name of the command or program that spawned the process is 
shown here. Whenever you enter a command, you are spawning a 
process. For example, if you enter the command 

$ 11 /usr/lib/acct 

you are creating a process with the command name 11. If a command 
requiring super-user privileges is executed, a # appears before the com¬ 
mand name. 

USER The login name of the user who created the process is displayed here. 
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TTYNAME 

START TIME 

END TIME 
REAL (SECS) 

CPU (SECS) 

MEAN SIZE(K) 


This is the name of the terminal from which the process was executed. 
If the process was not executed from a known terminal (for example, 
if it was executed via cron), then a question mark(?) appears in this 
column. 

The time that the process began executing (in hkmmiss format) is 
displayed here. 

This is the time {hh:mm:ss) that the process finished executing. 

The number of seconds that elapsed from START TIME to END TIME is 
shown in this column. 

This column shows how much of the CPU’s time a process used during 
its execution. 

This is a rough estimate (in kilobytes) of the amount of memory that 
a process used during execution. 

This estimate is based on the number of 512-byte memory segments 
held at process exit, rounded up to the next 512-byte unit. HP-UX Ac¬ 
counting reports memory usage only for resident, non-paged segments. 
This will include the process’s stack, global data segment, heap, non- 
shared code, some operating system data structures, and possibly some 
data (if not paged or shared). 

However, virtual memory statistics ARE NOT INCLUDED! 

Note also that only memory that is held for a complete sixtieth of a 
second will be reported; therefore, processes that execute for only a 
very short time (less than l/ 60 th of a second), may show zero memory 
usage! 
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The table below defines the columns that are not displayed on the standard report, but 
which can be displayed by using acctcom options. 


Column Header 

F 

STAT 


HOG FACTOR 


KCORE MIN 


Definition 

For a process created by fork which does not do an exec, this column 
takes the value 1 ; commands which require super-user privileges show 
a 2; super-user commands which do a fork without an exec show a 3; 
otherwise, this column shows a 0 . 

This column displays the system exit status. (This is not the status 
returned by exit to a parent process during wait). When a process 
terminates normally, this field shows a 0. If a command terminates 
abnormally, then a value other than zero is shown. For example, if 
you interrupt a command with the | DEL | key, this column will contain 
a 2. 

The hog factor is computed as the CPU time divided by REAL time; it 
provides a relative measure of the available CPU time used by the 
process during its execution. For example, a hog factor of less than 
0.50 indicates that the process spent less than half of its time using 
the CPU. A hog factor of 0.75 indicates that a process spent 75% of 
its time using the CPU. 

Provides a combined measurement of the amount of memory used 
(in kilobytes) and the length of time it was used (in minutes). It is 
computed as follows: 

KCORE MIN = CPU (SECS) ♦ MEAN SIZE(K) / 60 
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CPU SYS 

USER (SECS) 

CPU FACTOR 


CHARS TRNSFD 

BLOCKS R/W 


This is the portion of total CPU time that was spent executing oper¬ 
ating system code, such as system calls (for example, writing to disk). 

This is the remaining portion of CPU time. User CPU time is the 
amount of time actually spent executing a process’s code (rather than 
system code). 

Whenever you execute a command, the CPU spends part of its time 
actually executing the command’s code (user CPU time) and spends 
the rest of its time performing system functions, such as writing to 
the disk or terminal (system CPU time). That is, total CPU time is 
comprised of both system and user CPU time: 

CPU (SECS) = CPU SYS + USER (SECS) 

The CPU factor shows the ratio of user CPU time to total CPU time: 

CPU FACTOR = USER (SECS) / (CPU SYS + USER (SECS)) 

For example, if a command has a CPU factor of 0.35, that means 
that the CPU spent 35% of its time executing user code and 65% 
performing system functions. 

The number of characters (bytes) read and/or written by the com¬ 
mand is displayed in this column. 

This column shows the number of file system blocks read and/or 
written as a result of executing this command. This number is not 
directly related to CHARS TRNSFD and may vary each time the command 
is executed, because BLOCKS R/W is affected by directory searches made 
before opening files, other processes accessing the same files, and 
general file system activity. 
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Report Format Options 

When no report format options are specified, acctcom will produce a report containing 
only the default information. Optional information can be displayed only by using the 
report format options. Definitions of the report format options follow: 

Option Description 

-a Causes average statistics to be displayed at the end of the report. The fol¬ 

lowing information is shown: 

• total number of commands processed (cmds=xxx) 

• average real time per process (Real=x.xx) 

• average CPU time per process (CPU=x.xx) 

• average USER CPU time per process (uSER=x.xx) 

• average SYS CPU time per process (SYS=x.xx) 

• average characters transferred (CHARS=x.xx) 

• average blocks transferred (blk=x.xx) 

• average CPU factor (uSR/T0T=x. xx) 

• average HOG factor (H0 G=x.xx) 

-b Using this option will display the process records in reverse order: most re¬ 

cently executed commands will be shown first. 

-f Prints the fork/exec flag (f column) and process exit status (STAT column) 

on the report. 

-h Causes the optional HOG FACTOR column to be displayed, instead of the stan¬ 

dard mean memory size column MEAN SIZE(K). 

-i The optional I/O counts —CHARS TRNSFD and BLOCKS R/W— replace the stan¬ 

dard MEAN SIZE(K) column in the report. 

-k Replace the standard MEAN SIZE(K) column with KCORE MIN. 
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-m Show the default column MEAN SIZE(K) on the report. This option is used to 

include MEAN SIZE(K) when it has been bumped off by another option. For 
example, 

$ acctcora -km 

produces a report showing both KGORE MIN and MEAN SIZE(K). 

-r Include the optional CPU FACTOR column in the report. 

-t Show separate system and user CPU times (CPU SYS and USER (SECS) respec¬ 

tively). 

-V Using this option will suppress the printing of column headings at the top of 

the report. 

-q This option is the same as the -a option, except that individual process ac¬ 

counting records are not displayed—only the averages are displayed. 

-o of He Copy the input process accounting records to of He. 


Record Selection Options 

The options described here allow you to select the records that are included in the report 
produced by acctcom. The table shown below defines and provides examples for each 
option: 


Option Description 

-1 line Display only the processes that were executed from the user terminal 

/dev/line. For example, 

$ acctcom console 

would display records only for the processes that were created from the 
terminal console. 
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-u user 


-g group 


-s time 


-e time 


Show only the processes belonging to user, user can be any of the following: 

• a user ID (for example, acctcom -u 355) 

• user name (acctcom -u horatio) 

• a cross-hatch ^ (acctcom -u#) 

• a question mark ? (acctcom -u?) 

If # is specified as the user name, then only the commands that require 
super-user privileges will be displayed by acctcom. If ? is given as the user, 
then only the processes with unknown process IDs will be displayed. 

As an example, the following two commands are equivalent: 

$ acctcom -u 0 
$ acctcom -u root 


Show only the processes belonging to group, group may be specified as 
either a group name or group ID. For example, suppose the group pseudo 
with group ID 300 is defined in /etc/group; then the following two com¬ 
mands are equivalent: 

$ acctcom -g 300 
$ acctcom -g pseudo 


Select processes existing at or after time. Time is given in 24-hour format— 
hr[:min[:sec]]. The followiiig example would display all the processes that 
existed at or after 3:30pm: 

$ acctcom -s 15:30 


Select processes that existed at or before time. Time is supplied in 24-hour 
format hr[:min[:sec\]. The next example would display all the processes that 
existed between midnight and 12:15am: 

$ acctcom -e 0:15 
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-S time 


-E time 


-n pattern 


-H factor 


Select processes starting at or after time where time is in 24-hour for¬ 
mat. The following example would display all the processes that started 
at 1:30:42pm or after: 

$ acctcom -S 13:30:42 


Display only the processes that terminated at or before time^ where time 
is in 24-hour format hr\min[:sec]]. Note both the -S and -E options with 
the same time argument will cause acctcom to display only the processes 
that existed at the specified time. For example, to see all the processes 
that existed at exactly 30 minutes past noon, you would enter: 

$ acctcom -S 12:30 -E 12:30 


Show only the commands matching pattern, pattern can be a regular ex¬ 
pression as described in ed, except that + means one or more occurrences. 
For example, to display all processes that were created by executing the is 
command, you would enter: 

$ acctcom -n Is 

To display all the commands that start with acct, enter: 

$ acctcom -n acct 

To see all the commands that contain the letter m in their spelling, you 
would type: 

$ acctcom -n .*m,* 


Display only those processes whose hog factor exceeds factor. For example, 
$ acctcom -H 0.85 

would display all the processes that spent over 85% of their execution time 
in the CPU. You can use this option to find greedy processes—processes 
that are hogging the CPU. 
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-0 time Show only those processes whose system CPU time exceeds time, specified 
in seconds. The following example would be used to determine which 
processes took more than 8.25 seconds of operating system CPU time to 
execute: 

$ acctcom -0 8.25 

This option could be used to determine which processes are making heavy 
use of the operating system calls. 

-C sec Show only the processes whose total CPU time (SYS + USER) exceeds sec 

seconds. The next example would display all the processes that used over 
5.28 seconds of CPU time to execute: 

$ acctcom -C 5.28 

-I chars Display only the processes transferring more characters than the limit given 
by chars. For example, 

$ acctcom -I 10240 

will display all the processes that transferred over ten kilobytes of charac¬ 
ters (10 240 = 10 X 1024 bytes). 

Sample Reports 

The following sample report illustrates the use of acctcom without any options. The 
report generated is the standard report produced when no options are specified. 


$ acctcom 

ACCOUNTING RECORDS FROM: Thu Mar 21 12:52:26 1985 


COMMAND 



START 

END 

REAL 

CPU 

MEAN 

NAME 

USER 

TTYNAME 

TIME 

TIME 

(SECS) 

(SECS) 

SIZE(K) 

#accton 

root 

console 

12:52:26 

12:52:26 

0.12 

0.10 

19.00 

Is 

sarah 

tty07 

14:04:08 

14:04:08 

0.28 

0.23 

16.50 

ckpacct 

adm 

7 

14:30:00 

14:30:05 

5.13 

1.45 

24.00 

pwd 

bill 

ttylO 

15:09:07 

15:09:07 

0.48 

0.22 

22.50 

find 

sarah 

tty07 

18:51:37 

18:51:39 

2.73 

0.15 

26.50 

tabs 

root 

console 

19:10:18 

19:10:18 

0.92 

0.13 

23.50 

stty 

root 

console 

19:10:19 

19:10:19 

0.88 

0.08 

26.00 

mail 

bill 

ttylO 

19:10:21 

19:10:22 

1.78 

0.23 

28.50 

news 

root 

console 

19:10:23 

19:10:23 

0.73 

0.12 

23.00 

acctcom 

adm 

ttyaO 

19:53:16 

19:53:38 

22.58 

2.55 

28.50 


Now display all the processes created between 7:00pm and 7:30pm by the user root. In 
addition, include the optional CPU factor and average statistics in the output. 
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$ acctcom 

-S 19:00 

-E 19:30 

-u root -ah 



START AFT: 

Thu Mar 

21 19:00: 

00 1985 



END BEFOR: 

Thu Mar 

21 19:30: 

00 1985 



COMMAND 



START END REAL 

CPU 

HOG 

NAME 

USER 

TTYNAME 

TIME TIME (SECS) 

(SECS) 

FACTOR 

tabs 

root 

console 

19:10:18 19:10:18 0.92 

0.13 

0.14 

stty 

root 

console 

19:10:19 19:10:19 0.88 

0.08 

0.09 

news 

root 

console 

19:10:23 19:10:23 0.73 

0.12 

0.16 

cmds=3 Real=0.84 

CPU=0.11 

USER=0.02 SYS=0.09 CHAR 

=26.12 

BLK=11 

USR/T0T=0. 

19 H0G=O. 

13 





Sample reports are helpful, but the best way to learn the various acctcom options is to 
use them. Take a few minutes to experiment with this command; it is very powerful and 
can provide you with much useful information if used properly. 

Command Summary Report - acctcms 

The acctcms command takes process accounting records as input; but instead of reporting 
on the individual processes, acctcms generates a report on the commands that generated 
the process accounting records. The action of acctcms can be summarized as follows: 

1. acctcms looks through the input process accounting records and accumulates ex¬ 
ecution statistics for each unique command name. This information is stored in 
internal summary format—one record per command name. 

2. Depending on the acctcms options used, the command summary records created in 
step 1 are sorted. 

3. The command summary records are written to standard output in the internal 
summary format mentioned in step 1. (To get an ASCII, readable report of this 
information, you would use the -a option described later.) 

The syntax of the acctcms command is: 

acctcms [options] files 

where files is a list of the input process accounting files for which the command summary 
report is to be generated. 


System Accounting 307 



Producing a Readable Report - the -a option 

By default, the output of acctcms is in internal summary record format; if you display 

it to your terminal, all you see is gibberish. To get a human-readable report, use the -a 

option. 

The -a option causes acctcms to produce a report with descriptive column headings. 

Total and average (mean) execution statistics for each command are displayed one line 

per command—along with total and average statistics over all commands in the report. 

Descriptions of the columnar data produced by acctcms follow: 

Column Header Description 

COMMAND NAME The name of the command for which execution statistics are sum¬ 

marized. Unfortunately, all shell procedures are lumped together 
under the name sh, because only object modules are reported by the 
process accounting system. 

NUMBER CMOS The total number of times that the command was invoked. 

TOTAL KCOREMIN The total amount of kcore minutes accumulated for the command. 

(See the “Definitions of Information Produced by acctcom” for a 
more accurate description of kcore minutes.) 

TOTAL CPU-MIN The total CPU time that the named command has accumulated. 

TOTAL REAL-MIN Total accumulated real time seconds are displayed in this column. 

MEAN SIZE-K The average amount of memory (in kilobytes) consumed by the com¬ 

mand. 

MEAN CPU-MIN The average CPU time consumed per command invocation is shown 
here; the following equation shows how it is computed: 

MEAN CPU-MIN = TOTAL CPU-MIN / NUMBER CMOS 

HOG FACTOR This column shows the average hog factor over all invocations of the 

command. It is computed as: 

HOG FACTOR = TOTAL CPU-MIN / TOTAL REAL-MIN 

CHARS TRNSFD This column shows the total number of characters transferred by the 
command. Note that this number may sometimes be negative. 

BLOCKS READ A total count of the physical blocks read and written by the 

given command. (See the section “Displaying Process Accounting 
Records - acctcom” for details on the significance of this total.) 
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Note 


When only the -a option is specified, the report is sorted in de¬ 
scending order on the TOTAL KCOREMIN column: commands using 
more TOTAL KCOREMIN are shown before those using fewer TOTAL 
KCOREMIN. This report gives a relative measure of the amount of 
memory used over time by the various commands: commands to¬ 
ward the start of the report are making more use of memory re¬ 
sources than are commands toward the end of the report. 


Other Options 

In addition to the -a option, several other options can be used to control the format of 

the report generated by acctcms. Some options specify which field to sort the report on; 

other options control the printing of prime/non-prime time usage. The following table 

defines these options and illustrates their use. 

Option Description 

-c Sort the commands in descending order on TOTAL CPU-MIN, rather than the de¬ 

fault TOTAL KCOREMIN. This report can be used to determine which commands 
are using most of the computer’s CPU time. 

-n Causes the report to be sorted in descending order on the column named NUM¬ 

BER CMDS. Commands toward the start of this report are the ones used most 
frequently; commands toward the end are used least often. 

-j All commands invoked only once are combined on one line of the report; this 

line is denoted by having “***other” in the COMMAND NAME column. This option 
is useful for shortening a report that has many one-invocation commands. 

-o Used only with the -a option, -o causes the report to be generated only for 

commands that were executed during non-prime time (as specified in the holi¬ 
days file). You can use this option to get a non-prime time command summary 
report. 

-p Also used only with the -a option, -o elicits a report only only for commands 

that were executed during prime time (as specified in holidays). This option 
is used to get a prime time command summary report. 
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-apo When the options -o and -p are used together with -a, a combination prime and 
non-prime time report is produced. The output of this report is same as that 
produced by -a alone, except that the NUMBER CMOS, TOTAL CPU-MIN, and TOTAL 
REAL-MIN columns are divided into two columns—one for prime time totals, 
the other for non-prime time. (Prime time columns have a (P) header, while 
non-prime time columns are headed by (NP).) 

-8 Specifies that any named input files following the -s on the command line are 

already in internal summary format. This option is useful for merging previous 
acctcms reports with current reports. The following example uses -s to create a 
command summary report from previous process accounting files (pacct?) and 
the current process accounting file (pacct). The final ASCII report is stored in 
the file ascii^summary. 

$ acctcms pacct? > old.summary 
$ acctcms pacct > new_summary 

$ acctcms -as old_summary new_summary > ascii_summary 


Sample Report 

The ASCII reports produced by acctcms contain more than 80 characters per line. When 
these reports are displayed at an 80-column terminal, the lines wrap around on the screen. 
In addition, if the report is printed on an 80-column printer, some of the rightmost 
columns will be lost. Therefore, be sure to use either: 

1. a printer with compressed print capabilities, so that all of the report will fit on 
standard computer paper; or 

2. a printer with enough columns to display all the information—for example, a 132- 
column printer. 
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The following example generates a command summary report for the current process 
accounting file (no file is specified, so the current pacct file is assumed). By giving the -j 
option, all the commands that were executed only once are grouped under the command 
name ***other. Note also that total execution statistics for all commands are grouped 
under the command name TOTALS. 

$ acctcms -aj 

TOTAL COMMAND SUMMARY 


COMMAND 

NUMBER 

TOTAL 

TOTAL 

TOTAL 

MEAN 

MEAN 

HOG 

CHARS 

BLOCKS 

NAME 

CMDS 

KCOREMIN 

CPU-MIN 

REAL-MIN 

SIZE-K 

CPU-MIN 

FACTOR 

TRNSFD 

READ 

TOTALS 

61 

17.63 

0.38 

164.49 

46.25 

0.01 

0.00 

104553 

1027 

acctcms 

17 

12.13 

0.16 

0.35 

76.72 

0.01 

0.45 

49192 

306 

sh 

8 

2.43 

0.09 

152.86 

26.79 

0.01 

0.00 

9043 

163 

more 

3 

0.73 

0.02 

10.50 

31.00 

0.01 

0.00 

21618 

83 

11 

6 

0.61 

0.04 

0.11 

16.50 

0.01 

0.33 

5715 

95 

acctcom 

4 

0.58 

0.02 

0.07 

28.50 

0.01 

0.30 

15319 

42 

♦♦♦other 

9 

0.54 

0.02 

0.14 

25.26 

0.00 

0.16 

459 

161 

cat 

4 

0.19 

0.01 

0.35 

22.97 

0.00 

0.02 

3112 

52 

rm 

2 

0.11 

0.00 

0.02 

22.22 

0.00 

0.29 

0 

29 

chmod 

2 

0.10 

0.00 

0.01 

22.00 

0.00 

0.35 

0 

15 

accton 

2 

0.08 

0.00 

0.02 

19.00 

0.00 

0.29 

0 

22 

sed 

2 

0.08 

0.01 

0.04 

14.50 

0.00 

0.13 

73 

38 

echo 

2 

0.05 

0.00 

0.02 

20.00 

0.00 

0.16 

22 

21 


Creating Total Accounting Records 

Two commands —acctprcl and acctprc2 —are used to create total accounting records 
from the process accounting files. The output from acctprcl is supplied as input to 
acctprc2 which produces the total accounting records. These commands are normally 
invoked by runacct to produce daily accounting information. 

acctprcl 

This command reads process accounting records from standard input, adds login names 
corresponding to the user ID of each record, and then writes for each process an ASCII 
line showing: 

• the ID of the user that created the process 

• the user’s login name 

• prime CPU time in ticks (a “tick” is one sixtieth of a second) 

• non-prime CPU time, also in ticks 

• mean memory size (in memory segment units of 512 bytes each) 
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The format of acctprcl is: 
acctprcl [ctmp] 

Input must be redirected from a process accounting file. 

The following example creates a file, ascii_ptacct, containing ASCII process accounting 
information that can be used to create process total accounting records. This file is 
created from the current process accounting file pacct. 

$ acctprcl <pacct >ascii_ptacct 

Normally, acctprcl gets login names from the password file passwd, which is sufficient on 
systems where each user has a unique user ID. However, on systems where different users 
share the same user ID, the ctmp file should be specified; it helps acctprcl distinguish 
different login names that share the same user ID. 

When specified, ctmp is expected to contain a list of login sessions of the form created by 
acctconl, sorted by user ID and login name. 

acctprc2 

This command reads from standard input records of the form created by acctprcl; it 
then summarizes the records by user ID and name, and then writes the sorted summaries 
to standard output as total accounting records. The following example creates total 
accounting records for all processes in the current process accounting file pacct; the total 
accounting records are stored in the file ptacct. 

$ acctprcl <pacct Iacctprc2 >ptacct 
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Charging Fees to Users - chargefee 

System Accounting provides the capability to charge fees to specific users; the chargefee 
command is used to accomplish this task, chargefee allows you to charge generic units 
to a specific login name. The syntax of this command is: 

chargefee login_name number 

where number is the number of units to be charged to a particular user, and login_name 
is the login name of the user to whom number units are to be charged. 


note 

number can be any whole number in the range -32 768 to 32 767; 
when charging fees, keep in mind that the sum of each user’s fees 
must also be within this range. 


chargefee accumulates fee charge records in the file /usr/adm/fee. These records are 
then merged with other accounting records via runacct. 

Examples 

The following example charges 25 units to the user whose login name is horatio: 

$ chargefee horatio 25 

Suppose you inadvertently charged 247 units to the user named zimblits, and you want 
to return his charges to their original value. You would enter the following: 

$ chargefee zimblits -247 
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Summarizing and Reporting Accounting Information 

This final group of commands summarizes and reports accounting information. Certain 
commands display and merge total accounting files, while others generate the daily and 
monthly reports used to analyze system performance and bill users for resource usage. 
The following commands are discussed in this section: 

• prtacct —displays total accounting records 

• acctmerg —merges total accounting files 

• runacct —generates daily summary files and reports 

• prdaily —displays the daily summary files and reports created by runacct 

• monacct —creates monthly summary files and reports 

Displaying Total Accounting Records - prtacct 

The prtacct command allows you to display the contents of a process accounting file. Its 
format is 

prtacct file ^^headin^' 
where: 

• file is the name of the total accounting file to be displayed 

• '"heading^' is a comment to be included in the standard report header produced by 
prtacct 

The format of the prtacct report is described next and is followed by an example. 


314 System Accounting 


Report Format 

prtacct produces a columnar report with one line per total accounting record. Descriptive 
column headings are included in the report. Definitions of each column follow: 

Column Header Description 

UID The user ID of the owner of the total accounting record—i.e., the ID 

of the user for whom the total accounting record was created. 

LOGIN NAME The login name of the owner of the total accounting record is dis¬ 

played here. 

CPU (MINS) The total amount of CPU time (in minutes) that the user has con¬ 

sumed. This column is divided into prime and non-prime columns 
(prime and NPRIME respectively). Information in these columns is 
created through process accounting commands. 

KCORE-MINS This represents a cumulative measure of memory and CPU time 

that a user consumed (see “Definitions of Information Produced by 
acctcom” for a more precise definition). Information in this column 
is also divided into PRIME and NPRIME columns. This information is 
created through process accounting commands. 

CONNECT (MINS) Identifies the real time used (in minutes). In essence, what this 
column identifies is the amount of time that the user was logged in 
to the system. This column is also subdivided into PRIME and NPRIME 
columns. The connect session accounting commands are the source 
of this information. 

DISK BLOCKS The total number of disk blocks allocated to the user is shown here. 

This information is created via disk space accounting commands. 

# OF PROCS The total number process spawned by the user is displayed here. 

This information is created via the process accounting commands. 

# OF SESS This column shows how many times the user logged in. Connect 

session accounting commands create this data. 

# DISK SAMPLES This column indicates how many times the disk accounting was run 

to obtain the average number of disk blocks listed in the DISK BLOCKS 
column. 

FEE The number of fee units charged via chargefee is displayed here. 
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Example 

The following example displays disk total accounting records. First the total accounting 
records are created via disk space accounting commands; then they are displayed using 
prtacct When examining this report, take note of the following: 

1. The similarities between this and the sample report produced by diskusg (see “Disk 
Space Usage Accounting”), 

2. Only the columns relating to disk space usage have non-zero values, because the 
total accounting records were created only from disk space usage accounting com¬ 
mands. 

$ for file.system in ‘cat /etc/checklist* 

> do 

> diskusg $file_system >dtmp.‘basename $file_system‘ 

> done 

$ diskusg -s dtmp.* I sort +0n +1 lacctdisk >disktacct 
$ prtacct disktacct "DISC TOTAL ACCOUNTING RECORDS" 

Mar 26 17:01 1985 DISC TOTAL ACCOUNTING RECORDS Page 1 

LOGIN CPU (MINS) KCORE-MINS CONNECT (MINS) DISK # OF # OF # DISK 

FEE 

UID NAME PRIME NPRIME PRIME NPRIME PRIME NPRIME BLOCKS PROCS SESS SAMPLES 

0 TOTAL 0 0 0 0 0 0 11598 0 0 10 0 

0 root 0 0 0 0 0 0 10616 0 0 1 0 

1 bin 0 0 0 0 0 0 778 0 0 1 0 

4adm 00 00 0 0 96 001 0 

350 fred 00000 0 14 001 0 

351 bill 00000 0 32 001 0 

352 mike 00000 0 20 001 0 

353 sarah 00000 0 16 001 0 

354 molly 00000 0 22 001 0 

355 horatio 0000 0 0 2 001 0 

501 guest 00000 02001 0 
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Merging Total Accounting Files - acctmerg 

Normally executed by runacct, the acctmerg command merges separate total accounting 
files into a single total accounting file. All the total accounting records for a particular 
user name and ID are merged together to form one total accounting record for the given 
user name and ID. This command is useful for merging disk, connect session, and process 
total accounting files together to form a single, comprehensive total accounting file. 

acctmerg reads standard input and up to nine additional files, all in total accounting 
record format (or an ASCII version thereof). Its syntax is 

acctmerg [option^ [/n/e] ... 
where: 

• options control the report format and the manner in which records are merged. 

• file is one of up to nine files (in addition to standard input) that are to be merged 
into a single total accounting file, written to standard output. 

Command Options 

The following options may be used with acctmerg to control the report format and the 
manner in which the total accounting records are merged: 

Option Description 

-a acctmerg normally produces output as total accounting records. Using the - 

a option causes acctmerg to produce output in ASCII. Note that the output 
generated by using this option is the same as the report produced by prtacct^ 
except that no report headings or totals are displayed—only the columnar data 
is shown. 

-i In the default case, acctmerg assumes that its input files contain total account¬ 

ing records. If -i is specified, then acctmerg will expect input files to be in the 
ASCII format created by the -a option. 

-p This option simply echoes input records—no merging or processing is done. 

The output is displayed in the format produced by the -a option. 

-t Produces a single total accounting record that summarizes all input records. 

To see the ASCII version of this record, you must use the -t and -a options 
together: 

$ acctmerg -t -a <tot_acct_recs 

Note that -t and -a can be specified in any order, but they must be specified 
separately as shown. 
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-u Normally, acctmerg merges records that have the same user ID and user name. 

Using -u causes acctmerg to merge records on the basis of same user ID only- 
i.e., disregard the user name as a key on which to merge records. 

-V This option causes acctmerg to produce output in verbose ASCII format. The 
same report is produced as the -a option, except that floating point numbers 
are displayed in more precise notation; 

< mantissa>e< exponent> 


The -a, -v, and -i options are useful if you wish to edit total accounting records. For 
example, suppose that you have created a total accounting file {ptacct) containing process 
total accounting records, and you want to make some adjustments to these records. The 
following sequence could be used to make “repairs” to this file. 

$ acctmerg -v -a <ptacct >ptacct.ascii 
edit ptacct.ascii as desired ... 
then copy the changes back to ptacct 
$ acctmerg -i <ptacct.ascii >ptacct 
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Example 

The following example creates disk, process, and connect session total accounting records, 
merges them together, and stores the m.erged file in the file merged.f ile. 

$ # First, create disk space usage total accounting records (dtacct)... 

$ # 

$ for fs in ‘cat /etc/checklist* 

> do 

> diskusg $fs >dtmp.‘basename $fs‘ 

> done 

$ diskusg -s dtmp.* I sort +0n +1 lacctdisk >dtacct 
$ # 

$ # Now create connect session total accounting records (ctacct)... 

$ # 

$ acctconl </etc/wtmp |acctcon2 >ctacct 

$ # 

$ # Create process total accounting records (ptacct)... 

$ # 

$ >ptacct 

$ for p.file in pacct* 

> do 

> acctprcl <$p_file |acctprc2 »ptacct 

> done 

$ # 

$ # Now merge all the total accounting files (?tacct) into 
$ # a single total accounting file (tacct)... 

$ # 

$ acctmerg dtacct ctacct <ptacct >tacct 

Creating Daily Accounting Information - runacct 

runacct is the main daily accounting shell procedure. It is normally initiated via cron 
during non-prime hours, runacct processes disk, connect session, process, and fee ac¬ 
counting files. It prepares cumulative summary files for use by prdaily and/or for billing 
purposes. This section discusses the following aspects of runacct 

• files processed by runacct 

• the run-levels that runacct progresses through while executing 

• recovery from runacct failure 

• restarting runacct 

• reports produced by runacct 
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Files Processed by runacct 

The following files, processed by runacct^ are of particular interest to the reader. (File¬ 
names are given relative to the directory /usr/adm/acct) 

• nite/lineuse contains usage statistics for each terminal line on the system. This 
report is especially useful for detecting bad lines. If the ratio of logoffs to logins 
on a particular line exceeds 3 to 1, then there is a good possibility that the line is 
failing. 

• nite/daytacct contains total accounting records from the previous day. 

• sum/tacct contains accumulated total accounting records for each day’s total ac¬ 
counting records {nite/daytacct) and can be used for billing purposes. It is restarted 
each month or fiscal period by the monacct shell script. 

• sum/daycms is produced by acctcms. It contains the daily command summary. 
The ASCII version of this file is in nite/daycms. 

• sum/cms holds the accumulation of each day’s command summaries {sum/daycms). 
A new sum/cms file is created each month by monacct. The ASCII version of this 
file is in nite/cms. 

• sum/loginlog maintains a record of the last time each user logged in. 

• sum/rprtMMDD is the main daily accounting report created by runacct. This 
report can be printed via prdaily. 

runacct takes care not to damage files in the event of errors. A series of protection 
mechanisms are used that attempt to recognize errors, provide intelligent diagnostics, 
and terminate processing in such a way that runacct can be restarted with minimal 
intervention. To accomplish these goals, the following actions are performed by runacct: 

• runaccfs progress is recorded by writing descriptive messages to the file nite/active. 

• All diagnostics output during the execution of runacct are redirected to the file 
nite/fd2log. 

• If the files lock and lockl exist when runacct is invoked, an error message will be 
displayed, and execution will terminate. 

• The lastdate file contains the month and day that runacct was last run and is used 
to prevent more than one execution per day. 

• If runacct detects an error, a message is written to /dev/console., mail is sent to root 
and adm^ locks are removed, diagnostics files are saved, and execution is terminated. 
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The Run-Levels of runacct 


In order to allow runacct to be restartable, processing is broken down into separate 
re-entrant states. As runacct executes, it records its progress by writing the name of 
the most recently completed run-level into the file called /usr/adm/state file. After 
processing for a run-level is complete, runacct examines statefile to determine which 
run-level to enter next. When runacct reaches the final run-level (CLEANUP), the lock and 
lockl files are removed, and execution terminates. The following table describes runacct'^ 
run-levels: 


State Action 

SETUP The command turnacct switch is executed. The process accounting files, 

pacct?^ are moved to Spacct?.MMDD. The /etc/wtmp file is moved to 
nite/wtmp.MMDD with the current time added on the end. 

WTMPFIX nite/wtmp.MMDD is checked for correctness by wtmpfix. Some date 
changes will cause acctconl to fail, so wtmpfix attempts to adjust the time 
stamps in the nite/wtmp.MMDD file if a date change record appears. 

CONNECTl Connect session records are written to ctmp. The lineuse file is created, and 
the reboots file, showing all of the boot records found in nite/wtmp.MMDD, 
is created. 

CQNNECT2 ctmp is converted to connect session total accounting records in the file 
ctacct.MMDD. 

PROCESS The acctprcl and acctprc2 programs are used to convert the process 
accounting files, Spacctf.MMDD, to the total accounting records in 
placet?.MMDD. The Spacct and placet files are correlated by number so 
that if runacct fails, the unnecessary reprocessing of Spacct files will not 
occur. One precaution should be noted: When restarting runacct in this 
run-level, remove the last ptacct file; if you don’t, runacct will not finish. 


MERGE Merge the process and connect session total accounting records to form 

nite/daytacct. 

FEES Merge in any ASCII tacct records from the file fee into nite/daytacct. 

DISK On the day after the dodisk shell script runs, merge nite/disktacct with 

nite/daytacct. 

MERGETACCT Merge nite/daytacct with sum/tacct, the cumulative total accounting file. 

Each day, nite/daytacct is saved in sum/tacctMMDD, so that sum/tacct 
can be recreated in the event it becomes corrupted or lost. 
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CMS Merge in today’s command summary with the cumulative summary file 

sum/cms. Produce ASCII and internal format command summary files. 

USEREXIT Any installation-dependent (local) accounting programs can be run in this 
run-level. For example, you might want to execute commands that generate 
daily billing data for individual users (the shell script acct.bill in the 
section called “Sample System Accounting Shell Scripts” could be used 
for this purpose). To have local accounting programs executed by runacct^ 
simply enter the commands in runacct in the code for the USEREXIT run-level 
of runacct 

CLEANUP Clean up the temporary files, run prdaily and save its output in the file 
sum/rprtMMDD^ remove the locks, then exit. 

Recovering from Failure 

It is possible that runacct might fail and terminate abnormally. The primary reasons for 
runacct failure are: 

• a system “crash” 

• not enough disk space remaining in /usr 

• a corrupted wtmp file 

If the nite/activcMMDD file exists, check it first for error messages. If the nite/active 
file and lock files exist, check fd2log for any mysterious messages. The following are error 
messages produced by runacct and the recommended recovery actions: 

• ERROR: locks found, run aborted 

The files lock and lockl were found. These files must be removed before runacct 
can be restarted. 

• ERROR: acctg already run for date: check /usr/adm/acct/nite/lastdate 

The date in lastdate and today’s date are the same. Remove lastdate before restart¬ 
ing runacct 

• ERROR: turnacct switch returned rc=? 

Check the integrity of turnacct and accton. The accton program must be owned by 
root and have the setuid bit set. 
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• ERROR: Spacet?.MMDD already exists 

File setups probably already run. Check the status of files, then run setups manu- 
ally. 

• ERROR: /usr/adm/acct/nite/wtmp.MMDD already exists, run setup manually 

You must perform the SETUP step manually, because the daily wtmp file already 
exists. 

• ERROR: wtmpfix errors see /usr/adm/acct/nite/wtmperror 

wtmpfix detected a corrupted wtmp file. Sec the section “Fixing Corrupted Files” 
for details on fixing wtmp errors. 

• ERROR: connect acetg failed: check /usr/adm/acct/nite/log 

acctconl encountered a bad wtmp file. Again, see the section “Fixing Corrupted 
Files” on how to fix the file. 

• ERROR: Invalid run-level, check /usr/adm/acct/nite/active 

the file statefile is probably corrupted. Check statefile and read active before restart¬ 
ing. 

Restarting runacct 

runacct is normally run via cron only once per day. However, if an error occurs while 
executing runacct (as described above), it may be necessary to restart runacct. runacct 
has the following syntax: 

runacct [ mmdd [ state ]] 

When called without arguments, runacct assumes that it is being invoked for the first 
time on the current day; this is how runacct is invoked by cron. The argument mmdd is 
necessary if runacct is being restarted and specifies the month and day for which runacct 
will rerun the accounting. The entry point for processing is based on the contents of 
statefile. To override statefile^ include the desired entry state on the command line. 

For example, to start runacct, you would enter: 

$ nohup runacct 2> /usr/adm/acct/nite/fd21og & 

To restart runacct on the 26th day of March: 

$ nohup runacct 0326 2> /u8r/adm/acct/nite/fd21og & 

To restart runacct at run-level WTMPFIX on June 1st: 

$ nohup runacct 0601 WTMPFIX 2>/u8r/adm/acct/nite/fd21og k 
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Daily Reports 

runacct generates five basic reports upon each invocation. Brief descriptions of each 
report follow. Detailed descriptions of the reports are found in the following section, 
“Displaying runacct Reports — prdaily.” 

• Daily Line Usage Report —summarizes connect session accounting since the last 
invocation of runacct It provides a log of system reboots, power failure recoveries, 
and any other records dumped into /etc/wtmp via acctwtmp. In addition, it provides 
a breakdown of line utilization. 

• Daily Resource Usage Report —gives a summary of resource usage per individual 
user: it basically merges all the total accounting records for individual users and 
displays the records, one per user. 

• Daily Command Summary —summarizes resource usage data for individual com¬ 
mands since the last invocation of runacct The data included in this report is 
useful in determining the most heavily used commands; you can use these com¬ 
mands’ characteristics of resource utilization when “tuning” your system. 

This report is sorted by TOTAL KCOREMIN, an arbitrary but often-good yardstick for 
calculating “drain” on a system. 

• Monthly Total Command Summary— This report is exactly the same as the Daily 
Command Summary, except that the Daily Command Summary contains command 
summary information accumulated only since the last invocation of runacct, while 
the Monthly Total Command Summary summarizes commands from the start of 
the fiscal period to the current date. In other words, the monthly report reflects 
the data accumulated since the last invocation of monacct 

• Last Login —simply gives the date each user last logged in to the system. This 
could be a good source for finding likely candidates for the archives, or getting rid 
of unused login directories. 
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Displaying runacct Reports - prdaily 

As runacct finishes executing, it deposits a report of the current day’s accounting in the 
file /usr/adrn/acct/surn/rptmrndd, where mmdd is the month and day that the report 
was generated. The prdaily command is used to display the contents of any daily report 
file created by runacct Its syntax is 

prdaily [-/| [-c] [ mmdd ] 
where: 

• mmdd is an optional report date. If no date is specified, prdaily produces a report of 
the current day’s accounting information. Previous days’ accounting reports can be 
displayed by using the mmdd option and specifying the exact report date desired. 

• The -1 option prints a report of exceptional usage by login name for the speci¬ 
fied date. This option is used to determine which users are consuming excessive 
amounts of system resources. The limits for exceptional usage are kept in the file 
/usr/lib/acct/ptelus.awk and can be edited to reflect your installation’s require¬ 
ments. 

• Valid only for the current day’s accounting, the -c option is used to get a report of 
exceptional resource usage by command. This option is used to determine which 
commands are using excessive amounts of system resources. The limits for excep¬ 
tional usage are maintained in the file /usr/lib/acct/ptecms.awk and can be edited 
to reflect your system’s needs. 

The reports produced by rwnacc^ were described briefly in the previous sub-section. Now 
the reports are discussed in more detail. 
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Daily Line Usage Report 

In the first part of this report, the FROM/TO banner should alert you to the period reported 
on. The times are the date-time that the last report generated by runacct, and the date¬ 
time that the current report was generated. It is followed by a log of system reboots, 
shutdowns, power failure recoveries, and any other records dumped into wtmp by the 
acctwtmp command. 

The second part of the report is a breakdown of line utilization. The TOTAL DURATION 
shows how long the system was in a multi-user run-level. The columns of the report are 
defined in the following table: 

Column Description 

LINE The terminal line or access port being reported on. 

MINUTES The total number of minutes that the line was in use during the accounting 

period. 

PERCENT The percentage of TOTAL DURATION that the line was in use: 

PERCENT = (MINUTES / TOTAL DURATION) * 100 

# SESS Shows the number of times that this port was accessed for a login session. 

# ON Historically, this column displayed the number of times that the port was 

used to log a user on; but since login can no longer be executed explicitly 
to log in a new user, this column should be identical to # SESS. 

# OFF This column reflects not only the number of times a user logged off, but 

also any interrupts that occurred on the line. Generally, interrupts occur 
on a port when getty(lM) first invoked when the system is brought down 
to a multi-user run-level. This column comes into play when # OFF exceeds 
# ON by a large factor. This usually indicates that the multiplexer, modem, 
or cable is going bad, or that there is a bad connection somewhere. The 
most common cause of this is an unconnected cable dangling from the 
multiplexer. 

During real time, wtmp should be monitored as this is the file that connect session 
accounting is taken from. If it grows rapidly, execute acctconl to determine which line is 
the noisiest. If the interrupting is occurring at a furious rate, general system performance 
will be affected. 
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Daily Resource Usage Report 

This report gives a by-user breakdown of system resource usage. The format of this 
report is the same as that produced by the prtacct command. See the Report Format 
table for the prtacct command for definitions of the columnar data found in this report. 

Daily and Monthly Command Summary 

These two reports are the same, except that the Daily Command Summar>^ reports in¬ 
formation only for commands executed since the last invocation of runacct; the Monthly 
Command Summary contains information on commands executed since the last invoca¬ 
tion of monacct. 

The output of this report is identical to that produced by acetems. For definitions of 
the data found in this report, see the discussion of acetems in the “Process Accounting” 
section. 

Last Login 

This report simply shows the last date and time that each user logged in. The longer it 
has been since a particular user logged in, the more likely it is that the user’s files could 
be archived, or maybe even that the user could be removed from the system. 

Creating Monthly Accounting Reports - monacct 

monacct creates monthly summary files and reports; the resulting output is stored in 
the directory /usr/adm/acct/fiscal After creating its monthly reports, it removes the 
old daily accounting files from the directory /usr/adm/acct/sum and replaces them with 
new summary accounting files. 

monacct should be invoked once each month or accounting period. Its syntax is: 
monacct number 

where number indicates the which month or period it is (01=January, 12=December). If 
number is not specified, monacct assumes that it is being invoked for the current month; 
this default is useful if monacct is executed via cron on the first day of each month (as 
described in the “Daily Usage and Installation” section). 
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Descriptions of the files created in the acct/fiscal directory follow: 

• cmsl —contains the total command summary file for the accounting period denoted 
by ?. The file is stored in internal summary format. Therefore, to display this file, 
you must use the acctcms command. The following example shows how to display 
this file for the month of June: 

$ acctcms -a -s /usr/adm/acct/nite/fiscal/cms06 

• fiscrptl —contains a report similar to that produced by prdaily. The report shows 
line and resource usage for the month represented by ?. The following would display 
the fiscal accounting file for the month of November: 

$ cat /usr/adm/acct/nite/fiscal/fiscrptll 

• tacct ?—is the total accounting file for the month represented by ?. To display this 
file, you must use the prtacct command. The following would display the total 
accounting summary file for the month of January: 

$ prtacct /usr/adm/acct/fiscal/tacctOl "JANUARY TOTAL ACCOUNTING" 
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Updating the Holidays File 

The file /usr/Ub/acct/holidays contains the information that System Accounting 
needs to distinguish between prime and non-prime time. It contains the following in¬ 
formation: 

1. Comment Lines. Comment lines are entered by placing an asterisk (*) as the first 
character in the line; they may appear anywhere in the file. 

2. Year Designation Line. This line should be the first non-comment line in the file 
and must appear only once. The line consists of three four-digit numbers (leading 
blanks and tabs are ignored). The first number designates the year; the second 
denotes the time (in 24-hour format) that prime time starts; the third gives the 
time that prime time ends and non-prime time starts. 

For example, to specify the year as 1985, prime time at 9:00 a.m., and non-prime 
time at 4:30 p.m., the following entry would be appropriate: 

1982 0900 1630 

A special condition allowed for in the time field is that 2400 is automatically con¬ 
verted to 0000. 

3. Company Holiday Lines. These entries follow the year designation line. Company 
holidays are days when few people should be using the computer. Therefore, System 
Accounting assumes that non-prime time is in effect during the entire 24 hours of 
a specified holiday. 

Company holiday lines have the following format: 

day_of_year Month Day Description of Holiday 

The day_of_year field is a number in the range 1 through 366, corresponding to the 
day of the year for the particular holiday (leading blanks and tabs are ignored). 
The remaining fields are simply commentary and are not used by other programs. 


Note 

As delivered, the holidays file contains valid entries for Hewlett- 
Packard’s prime/non-prime time, and holidays. You should check 
this file and edit it as necessary to reflect your organization’s re¬ 
quirements. 
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Fixing Corrupted Files 

System Accounting files may become corrupted or lost. Some of these files can simply 
be ignored or restored from the file save backup. However, certain files must be fixed in 
order to maintain the integrity of System Accounting. 

Fixing wtmp Errors 

The wtmp files seem to cause the most problems in the daily operation of System Ac¬ 
counting. When the date is changed and HP-UX is switched into multi-user mode, a set 
of date change records is written into /etc/wtmp. The wtmp fix command is designed to 
adjust the time stamps in the wtmp records when a date change is encountered. However, 
some combinations of date changes and reboots won't be caught by wtmpfix and cause 
acctconl to fail. The following steps show how to "patch” a damaged wtmp file. 

$ cd /usr/adm/acct/nite 
$ fwtmp <wtmp.MMDD >wtmp.teinp 

Using an editor, delete corrupted records or 
delete all records from beginning up to the date change 
$ fwtmp -ic <wtmp.temp >wtmp.MMDD 
$ rm wtmp.temp 

If the wtmp file is beyond repair, create a null wtmp file. This will prevent any charging 
of connect time, acctprcl will not be able to determine which login owned a particular 
process, but it will be charged to the login that is first in the password file for that user 
ID. 
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Fixing tacct Errors 

If your installation is using System Accounting to charge users for system resource usage, 
the integrity of sum/tacct is quite important. If sum/tacct ever becomes corrupted, 
then check the contents of sum/tacctprev with the command prtacct If it looks correct, 
then the latest sum/tacct.MMDD should be patched up, and sum/tacct should then be 
recreated. A simple patch procedure would be: 

$ cd /usr/adm/acct/sum 
$ acctmerg -a -v <tacct .MMDD >tacct. temp 

Using an editor, remove the bad records and 
write duplicate UID records to another file 
$ acctmerg -i <tacct.temp >tacct.MMDD 
$ acctmerg tacctprev <tacct.MMDD >tacct 
$ rm tacct.temp 


Remember that monacct removes all the tacct.MMDD files; therefore, sum/tacct can be 
recreated by merging these files together. 
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Sample Accounting Shell Scripts 

grpdusg 

This shell script displays disk space usage totals for the users who are members of a 
specified group. The syntax of this command is: 

grpdusg group_name 

where group_name is the name of the group for which disk space accounting information 
is to be generated. 

For example, 

$ grpdusg pseudo 

generates disk space usage information for all the users in the group pseudo. 
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The Shell Script 

# Check for the group-name parameter. 

# 

if [ $# -ne 1 ] 

then echo "\nUsage: grpdusg group-name\n" 

exit 1 
fi 

echo "\nOne moment please...\n" 

# 

# Use the find command to find all the files whose owners are members of 

# group-name. Pipe the output from find into acctdusg which will accumulate 

# disk space usage information for the users in group-name. 

# Note: 

# - accounting data is temporarily stored in _${l}_tmp 

# - error messages are stored temporarily in _${l}_err 

# - if files exist that have no owners, then the names of 

# these files are stored in _no_owners 

# 

fn=_${l}_ 

find / -group $1 -print 2>$*Cfn}err I acctdusg -u _no_owners >$‘(fn}tmp 
# 

# Remove the _no_owners file if its size is not greater than zero. 

# 

if [ -s _no_owners ] 

then echo "\nFiles having no owners exist--check _no_owners\n" 

else rm _no_owners 

echo "\nAll files have owners-- _no_owners not created\n" 
fi 

# 

# Use echo and awk to display disk usage totals for this group. 

# 

echo "XnDisc space usage information (group is ${!}):\n" 

awk ’BEGIN {print "\n_UID_USER NAME_BLOCKS"} 

{ sum += $3 ; # add up total disk blocks used 

print $0 # display information for user 

END { print "\nT0TAL DISC SPACE USAGE= ", sum. "blocks" >’ ${fn>tmp 

# 

# Remove temporary files, then exit. 

# 

rm ${fn}* 
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acct_bill 

acct^bill takes as input a total accounting file and produces as output billing totals for 
all users found in the input file. The syntax of acct^bill is: 

acct.bill [ mmdd ] 

If the optional mmdd is not specified, then acct_bill takes as input the current day’s 
total accounting file [acct/nite/daytacct)\ if mmdd is given, then input is taken from the 
total accounting file for the date specified by mmdd {acct/sum/tacctmmdd). Output is 
written to the file billsmmdd, where mmdd is the date given with the command, or the 
current date if mmdd was not specified with the command. 

Examples 

To generate billing information for the current day, simply enter: 

$ acct_bill 

and the billing information will be stored in the file acct/sum/billsmmdd, where mmdd 
is the current date. 

To create billing information for January 23rd, you would enter: 

$ acct_bill 0123 

after which the billing information would be stored in the file called acct/sum/bUls0123. 

To automatically generate daily billing totals for all users, you should call accLbill with¬ 
out the date argument from the USEREXIT run-level of runacct. 

Output Produced by accLbill 

The output of acct_bill contains one line per user and has the following format: 
user_ID user_name billing^amount 

where user_ID and user_name identify the user who is being billed, and billing_amount 
shows the total amount that the user is to be charged. 
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billing^amount is computed by multiplying accounting coefficients (found in the shell 
script) by columns of the report generated by prtacct. Assuming that billing amounts 
are in dollars, the coefficients (as they are currently shown) produce the following billing 
amounts: 

• 10 cents for every minute of prime CPU time consumed 

• five cents for every minute of non-prime GPU time consumed 

• a half cent for every prime kcore minute used 

• two-tenths of a cent for every non-prime kcore minute 

• a half cent for every prime connect time minute 

• two-tenths of a cent for every non-prime connect minute 

• two-and-a-half cents for every block of disk space used 

• two-and-a-half cents for every process spawned by the user 

• ten cents for every connect session 

• each fee unit charged via charge fee counts as one cent 

You should experiment with this command by altering the coefficients to see how 
billing_amount is affected. After gaining confidence with this shell script, you can alter 
the coefficients to suit your installation’s needs. 
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The Shell Script 

_date=‘date +y,my,d‘ 

_outfile=/usr/adm/acct/sum/bills 
_infile=/u8r/adm/acct 
# 

# Set _infile and _outfile, based on whether or not MMDD was given 

# 

if [ $# -eq 0 ] 

then # Generate billing data for current day. 

_infile=${_infile}/nite/daytacct 
_outfile=${_outfile}${_date} 

else # Create billing data for date given (MMDD). 

_infile=$<_infile}/sum/tacct${l} 

_outfile=${_outfile>${l} 
fi 

# 

# Create a file containing the ASCII equivalent of the input total 

# accounting file (tacct_ASC.tmp_). The file can then be supplied as input 

# to awk, which will generate billing data for each user. 

# 

acctmerg -a -t <$_infile >tacct_ASC.tmp_ # output TOTAL amount first 
acctmerg -a <$_infile »tacct_ASC.tmp_ # append users’ total accounting 

records 
# 

# Using awk, compute billing totals for each user in the total accounting file. 

# 

awk ’BEGIN { 

# ACCOUNTING COEFFICIENTS 

cpu.P =0.10 #0.10 monetary units per minute of prime CPU time 

cpu_NP=0.05 # 0.05 monetary units per non-prime CPU minute used 

kcm_P =0.005 # for prime kcore minutes consumed 

kcm_NP=0.002 # for non-prime kcore minutes used 

con_P =0.005 # prime connect (real) time 

con_NP=0.002 # non-prime connect time used 

blk = 0.025 # number of blocks used 

prc = 0.025 # number of processes spawned 

ses = 0.10 # number of connect sessions 

fee = 0.01 # 100 charge units per monetary unit 

# **♦**♦♦♦♦♦**♦**♦♦♦♦***♦**♦♦♦*♦*♦**♦****♦♦♦*♦♦♦♦♦**♦ 

} 

# Start computing billing amounts for each user. 

< _sum = cpu_P*$3 + kcm_P*$5 + con_P*$7 # compute prime usage 

_sum+= cpu_NP*$4+ kcm_NP*$6+ con_NP*$8 # add non-prime usage 

_sum+= blk*$9 + prc*$10 + ses*$ll + fee*$13 # add remaining amounts 

printf "y,-8s y,-10s y,10.3f\n", $1, $2, _sum # display user total 

}’ tacct_ASC.tmp_ >$_outfile # write output from awk to appropriate file 
rm tacct^ASC.tmp_ # remove the temporary ASCII file 
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System Accounting Files 

Descriptions of the different files processed by HP-UX System Accounting are found in 
this section. The files are grouped according to the directory in which they are found. 


Files in the /usr/adm directory 


Filename 

diskdiag 

dtrnp 

fee 

pacct 

pacct? 


Contents 

Diagnostic output from the execution of disk space accounting com¬ 
mands. 

Output from the acctdusg program. 

Output from the /chargefee command (ASCII total accounting 
records). 

The current active process accounting file. 

Process accounting files switched via turnacct switch. 


Files in the /usr/adm/acct/nite directory 


Filename 

active 


ctacct,MMDD 

ctmp 

daycms 

daytacct 

disktacct 

fd2log 


Contents 

Used by runacct to record progress. It contains warning and error 
messages. activeMMDD is the same as active after runacct detects 
an error. 

Total accounting records created from connect session accounting. 
Output of acctconl^coim^ct session records. 

ASCII daily command summary used by prdaily. 

Total accounting records for current day. 

Total accounting records created by the dodisk command. 
Diagnostic output from the execution of runacct (see crontab entry). 


lastdate 

lock & lockl 

lineuse 

log 


The last day that runacct was executed, in date -h%m%d format. 
(See date(l) for a description of -h%m%d date format.) 

Used to control serial use of runacct. 

Terminal (tty) line usage report used by prdaily. 

Diagnostics output from acctconl. 
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logMMDD 

reboots 

statefile 

tmpwtmp 

wtmperror 

wtmperrorMMDD 

wtmp.MMDD 


Same as log after runacct detects an error. 

Contains beginning and ending dates from wtmp, and a listing of 
reboots. 

Used to record the current run-level being executed by runacct 
wtmp file, corrected by wtmpfix. 

Error messages, if any, from wtmpfix. 

Same as wtmperror after runacct detects an error. 

The previous day’s wtmp file. 


Files in the /usr/adm/acct/sum directory 


Filename 

cms 

cmsprev 

daycms 

loginlog 

pacct.MMDD 

rptMMDD 

tacct 

tacctprev 

tacctMMDD 

wtmp.MMDD 


Contents 

Total command summary file for current month in internal summary 
format. 

Command summary file without latest update. 

Command summary file for previous day in internal summary for¬ 
mat. 

Shows the last login date for each user. 

Concatenated version of all process accounting files for the date 
MMDD. This file is removed after reboot. 

Daily accounting report for date MMDD. 

Cumulative total accounting file for current month. 

Same as tacct without latest update. 

Total accounting file for date MMDD, 

Saved copy of wtmp file for MMDD. Removed after reboot. 
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Files in the /usr/adm/acct/fiscai directory 

Filename Contents 

cms? Total command summary for month ? in internal summary format. 

fiscrpt? Report similar to prdaily for the month ?. 

tacct? Total accounting file for the month ?. 
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Notes 
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Using the FSCK Command 

Introduction 

The file system consistency check (/etc/fsck) corrects inconsistent information in your 
file system. You must have a thorough understanding of the file system before making 
any f sck decisions. Read “File System Implementation” in Chapter 4 before proceeding. 

f 8ck should be performed in the following situations: 

• f sck will run automatically during bootup if you had an unclean shutdown. This 
will be the case if you had a system crash or power failure. 

The fsck will run as the system enters run-level 2. As shipped, your system will 
do this automatically if it detects an improper shutdown, via the bcheckrc entry 
in /etc/inittab. An improper shutdown means you didn’t shut down your system 
using the shutdown or reboot commands described in “Shutting Down the System” 
in Chapter 4. f sclean is used to detect an improper shutdown. 

• You should run fsck any time you suspect problems with the HP-UX file system. 

There is no specific problem you can relate to file system corruption. If your HP-UX 
system doesn’t behave like you think it should, run fsck. 

• You should run fsck occasionally even though fsclean (run from /etc/bcheckrc) 
does not indicate the need to do so (particularly if your system exhibits unusual 
behavior). The backup script has an option to run fsck -n after the backup is 
performed; you should use this option, fsck -n reports discrepancies, but does not 
fix them, so it can be safely rim by cron. 

The remainder of this article explains: 

• how the file system is updated 

• how the file system can be corrupted 

• how corrective actions used by fsck can recover a corrupted disk 
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Updating the HP-UX File System 

Every time a file is modified, the HP-UX Operating System performs a series of file 
system updates. These updates are designed to ensure a consistent file system. The 
problem occurs when this series of updating tasks is interrupted. Since some of these 
tasks may have completed, it is important to know their execution order so that good 
decisions can be made when repairing a corrupted disk. 

There are five types of file system updates: 

• Super-block 

• i-nodes 

• file-attribute file 

• data blocks (directories and files) 

• free map 

Super-Block 

The super-block contains: 

• an identification of the disk format (HP-UX) 

• a flag describing the integrity of the directory structure 

• the root directory name 

• the volume block size 

• the location and size of the boot area 

• the location of the file attributes file 

• the largest addressable block 

The super-block of a mounted file system is written to the file system whenever a umount 
or sync command is issued. The root file system is always mounted. 
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I-nodes 

An i-node contains information about: 

• the type of i-node (directory, data, or special) 

• the name and i-node of it’s parent directory 

• the list of blocks and extents claimed by the i-node 

• the size of the file 

• protection, access, user and group affiliation 

• date and time stamps 

An i-node is written to the file system upon closure of the file associated with the i-node. 
All in-core blocks are also written to the file system upon execution of a sync system 
call. 

File Attributes File 

The file attribute file contains information about: 

• the i-node for the root directory 

• the free map 

• an entry for each file on the file system 

• file extents 

The location of the file attribute file is maintained in the super-block, and is used in 
conjunction with i-nodes to maintain the location and integrity of the data in your HP- 
UX system. 
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Data Blocks 

A data block may contain either file or directory entries. Each directory entry consists 
of a file name and an i-node number. 

Data blocks are written to the file system whenever they have been modified and released 
by the operating system. 

Free Map Blocks 

The file attribute file contains a map of the file system (the free map), which is used to 
determine available file space. In the free map, each bit represents a block on the volume. 
If a bit is set, then it’s corresponding block is being used; if not, then that block is free. 

Free map blocks are written to the file system whenever they have been modified and 
released by the operating system. 
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Corruption of the File System 

A file system can become corrupt in a variety of ways. The most common ways are 

improper shutdown procedures and hardware failures. 

Improper System Shutdown and Startup 

File systems may become corrupt when proper shutdown procedures are not observed: 

• not having a quiescent system before stopping the CPU 

• forgetting to sync the system prior to halting the CPU 

• not executing the shutdown command when halting the system 

• physically write-protecting a mounted file system 

• taking a mounted file system off-line 

File systems may become further corrupted if proper startup procedures are not observed: 

• not checking a file system for inconsistencies 

• not repairing inconsistencies 

Allowing a corrupted file system to be further modified can be disastrous. 

Hardware Failure 

While your Hewlett-Packard Series 500 computer system and disks are highly reliable, 
it is good to remember that any piece of hardware can fail at any time. This isn’t a 
prediction of gloom, but merely a word of caution to you as the system administrator, 
to make small steps of precaution. By following the preventative maintenance outlined 
in your installation guides and in this manual, you should be able to avert any serious 
problems. Failures can be as subtle as a bad block on a disk pack, or as blatant as a 
non-functional disk controller. 


Using the FSCK Command 345 



Detection and Correction of Corruption 

A quiescent file system may be checked for structural integrity by executing fsck. The 
f sck command checks on the data which is intrinsically redundant in a file system. The 
redundant data is either read from the file system or computed from known values. A 
quiescent state is important during the checking of a file system because of the multipass 
nature of the fsck program. 

When an inconsistency is discovered, fsck reports the inconsistency for the system ad¬ 
ministrator. The system administrator then must choose a corrective action. 

One of the most commonly corrupted items is the super-block. The super-block is prone 
to corruption because every change to the file system’s blocks or i-nodes modifies the 
super-block. 

The super-block and its associated parts are most often corrupted when the computer is 
halted and the last command involving output to the file system was not a sync command. 

File-System Size and I-node-List Size 

The file-system size must be larger than the number of blocks used by the super-block 
and the number of blocks used by the list of i-nodes. The number of i-nodes must be less 
than 65,535. The file system size and i-node list size are critical pieces of information to 
the fsck program. While there is no way to actually check these sizes, fsck can check 
for them being within reasonable bounds. All other checks of the file system depend on 
the correctness of these sizes, fsck also checks that the last allocated block can be read 
as a test for possible corruption of the super-block. 

The file attribute file and the i-node list can be checked for: 

• incorrect link counts 

• blocks not accounted for anywhere 

• bad i-node format 

• files pointing to unallocated i-nodes 

• i-node numbers out of range 

• multiply linked directories 

• link to the parent directory 


346 Using the FSCK Command 



Free Map 

The free map is part of the file attribute file (also known as the file attribute list or FAL), 
a file which represents all of the inodes on a volume. This map describes all blocks on 
the volume, including the boot area, super-block, file attribute file, and the rest of the 
volume. In the FAL, inode 0 (the inode for the FAL) and inode 1 (the inode for the root 
directory) are first allocated. 

Inodes 3 through the end of the free map are allocated to represent all the blocks on the 
volume. Each block is represented by a single bit in the free map. Since the free map 
takes up an integral number of inode entries in the FAL, and each inode entry takes 128 
bytes (representing 128x8=1024 logical blocks on a disk), the number of inode entries 
that the free map will consume will be: 

( (number bytes on disk)-^(block size) —1 )h-(128x8) -f- 1 

For example, consider an HP 7935 (a 404 Mbyte disk) which has been initialized with 
a logical block size of 1024. Using our formula, 386 inode entries in the FAL will be 
devoted to the free map, so inodes 3 thru 388 will be allocated as the free map on that 
disk. 

f sck will check each free map entry for: 

• blocks claimed by more than one i-node, or by the free map 

• blocks claimed by an i-node or the free list outside the range of the file system 

A check is made to see that all the blocks in the file system were found. 
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Executing the FSCK Command 

Only the system administrator should run fsck. If this check discovers an inconsistency, 
corrective action must be taken. 

fsck should be executed using a character special device file, not a block special device 
file. All file systems except the root and virtual memory file systems should be un¬ 
mounted. If you shut down the system using shutdown, all file systems except root will 
be unmounted and you will be in run-level s. Refer to Adding Peripheral Devices” in 
Chapter 5 for a discussion on block and character devices, and naming conventions for 
device files. 

The syntax for fsck is: 

/etc/fsck [-y] [-n] [sj [-d] [-pj [-P] [file_systemj 

where all the arguments are optional. A description of each follows: 

file_system The character device file of the volume you wish to check, such as 
/dev/rdsk/lsO. Usually you will want to do an fsck on all volumes con¬ 
nected to your system. If you do not supply the file-system argument, the 
fsck command will check all file systems listed in the /etc/checklist file 
and marked rw or ro. 

default Interactive mode. 

The interactive mode allows you to choose whether or not to perform a 
corrective action. 

-p Preening option. 

This option fixes many potential problems, but never removes data. When 
you preen the system, you may be checking some file systems in parallel 
and are not running interactively, fsck will decide what to do, and if it 
can’t deal with a situation, it will terminate. For the inconsistencies the 
preening option can fix. it will print a message identifying the file system, 
and the corrective action taken. 

Since it was created to be run non-interactively, when it finishes it does 
not tell you if you need to reboot the system. You must determine that 
from the return code (refer to fsck(lM)). 
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The preening option is the option used if bcheckrc detects an unclean shut¬ 
down during system boot. This option operates the same as the preen (-p) 
option except all file systems which were cleanly unmounted will not be 
checked. For a discussion on clean file systems refer to the chapter “System 
Startup and Shutdown”, the section, “HP-UX Starts the Init Process”. Us¬ 
ing this option can greatly decrease the amount of time required to reboot 
a system which was brought down cleanly. 

Yes option. 

Using the -y option can be very dangerous. This option causes fsck to 
answer YES to all questions, which might remove data. Do not use the -y 

option if you have important data on your file system unless you have first 
used the -n option and understand the potential damage. 

No option. 

Using the -n option causes fsck to answer NO to all questions. This will 
never remove data, so is very safe. You can use the -n option any time; 
multi-user, single-user, or background. 

If you use fsck with the -n option in multi-user mode, you may come up 
with some inconsistencies due to file system action. However, you will 
never damage your system. 

When checking the integrity of your file system, you may desire to have 
more than the cursory phase summaries printed at your console. This is 
especially true if you are trying to pinpoint where you are having problems. 
To do this, fsck has been written with the -d option. 

/etc/fsck “d /dev/rdsk/OsO 

fsck was designed with five levels of debug information (hence -d); you can 
have additional levels of these messages printed by increasing the number 
of -d’s. Of course since there are five levels of debug information, the most 
you can do is: 

/etc/fsck -ddddd /dev/rdsk/OsO 

Some caution should be used when specifying the debug option—using 
more than two -d’s will produce copious output (probably more than you 
would want to wade through, unless you are really serious about reading 
it). In the discussion which follows, we’ll be walking through an fsck on 
an example system, with two levels of debug information. 
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-s This option reconstructs the free map. In the first pass of executing fsck 

you may find a conflict between the free map and a file. As an example, 
the file system may think a block on the volume is free, but you know that 
your mother-in-law’s mailing list really resides there. Since you don’t want 
to lose this data, you need some way to tell the system that a file really is 
using this block. 

To do this, use the -s argument to unconditionally reconstruct the free 
map: 

/etc/fsck ’8 /dev/rdsk/OsO 

When fsck executes, it will calculate what blocks are really free and then 
build a new free map in memory. When this is done, the program will 
overwrite the old free map (which resides in the file-attribute file). 

If -s is used to correct a problem on a virtual memory device (which will 
be the case if you only have one disk on your system), there is a high 
probability that the final step in fsck will fail and you will be forced to 
re-boot. Should this occur, an appropriate error message will be printed. 
No damage should occur. 

In any situation in which you use the -s option, once complete you should 
always execute fsck again to certify that your system is clean. 

You should always run the shutdown command before executing fsck. shutdown will put 
your system into run-level s (the system administrative run-level). Running fsck when 
there is file system activity may cause loss of data. For more information on shutting 
down your Series 500, see the “Shutting Down Your System” section of Chapter 4. 

A directory with the name /lost+found must exist on the file system being examined 
before fsck is run. /lost+found should have been created on your root volume when you 
installed HP-UX on your system. The fsck command uses this directory for any problem 
files that it finds. After you run fsck, examine the files placed in /lost+found and move 
them to where they belong or remove them. You should clear the /lost+found directory 
before you execute fsck again. 
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To place these files, follow this procedure: 

1. Change to the lost+found directory for the file system. For example, cd /lost+found 
for the root file system. 

2. Find out what type of file it is (executable, text, etc), and who owns the file, by 
typing: 

file * 

11 * 

If the file is text, see what^s in it by typing: 
more filename 

3. If the file is executable, then: 

a. If the file has an SCCS ID string, the what command will list it. 

b. If the file does not have an SCCS ID string, use the strings command to 
print the literal strings from the file. The strings (for example, error message 
strings) may help identify the owner. 

4. From this information, determine where the file belongs, or who it belongs to, and 
move the file to the correct directory. 

A Walk Through 

To best illustrate the use of the f sck command, let’s walk through a file system integrity 
check on a common configuration. This fsck was done on a Model 540 (pod mount) 
system with one HP 7914 disk drive. Since our example system has only one disk, we 
know that: 

• the HP 7914 will be the root file system, 

• the root file system will be mounted, 

• and this disk will also be the virtual memory device. 

Normally you would want to run fsck on an unmounted file system, but since we are 
using the only disk, this is impossible. Because of this, fsck will print some warning 
messages—don’t worry about them. 

/etc/fsck -dd /dev/rdsk/OsO 

Checking /dev/rdsk/OsO 

WARNING: This device is the root device. 

WARNING: This device is used by virtual memory. 
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These messages are normal on most systems, since the root and virtual memory volumes 
will be the device in /etc/checklist. If you are not in a quiescent state, you may get a 
warning similar to: 

WARNING: 22 superfluous processes are running. 

For accurate diagnostics, only init, a shell, and fsck should be running. 

Quit? yes 

You do not want to run an fsck while in this state, so type yes in response to Quit? The 
program will terminate. 

Volume Header Information 

As the first step of the file system integrity checking process, a summary of volume 
header (super-block) information will be printed: 

Volume Header; 

format = 0x700 

corrupt = 0 

block size = 1024 

max block = 129023 

FA file starts at block 69087 

For more information on the meaning of this information, see the fs(5) entry in the 
HP-UX Reference manual. 

Phase 1: Checking Directories 

After printing the volume header information, fsck next creates a list of all extents 
(groups of contiguous disk blocks), that the system believes are claimed by a file or that 
are free (as identified by the free map). Each entry in the list consists of the starting 
address of an extent and the size of the extent. 

During this phase of its execution, fsck also traverses all directories in the file system, 
creating a map of all i-nodes pointed to by directory entries (a map of all i-nodes in the 
file system). Since we are printing two levels of debug information, we will also see which 
directory is currently being searched: 
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♦♦Checking Directories. 

Finding inodes. 

Traversing directories. 

Processing directory /users/hpux/marka/BASIC/CHll 
Processing directory /users/hpux/clarke 
Processing directory /users/hpux/michael 


Processing directory /users/hpux/michael/manlm 
Processing directory /users/hpux/marc 


Processing directory /image/demo/LIBRARY 
Processing directory /image/docs 
Building extent tree. 

As you can see, printing all directories on the system produces copious output; in our 
example, f sck produced 12 pages of Processing directory messages (our example is a 22 
user system). Following all these messages are some summary statistics. 

Free map built. Number of free blocks = 19255. Last block = 129023. 

Max tree depth = 133 

Number of nodes in tree = 15522 

Don’t be alarmed if an fsck on your system results in values different from these (even 
if you have an HP 7914 connected to a Model 540); how a system is used, how big it’s 
boot area is and other factors affect fsck results more than the actual hardware. What 
you should be concerned about are results which totally conflict with anything you’ve 
seen in the past. 

Phase 2: Checking Blocks 

Once phase 1 (checking directories) is completed, phase 2 begins in which fsck begins 
looking for inconsistencies. It examines the list of extents built previously in phase 1. 
The list identifies all disk allocations. In a consistent file system, this list includes every 
block on the disk. Any extents not claimed by either a file or the free map are reported 
at the end of this process along with the total number of unclaimed blocks in the file 
system. 
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♦♦Checking Blocks. 


Number of tree nodes checked: 15522 
Number of unclaimed blocks: 23. 

MULTIPLE FILES CLAIM THE SAME SPACE ON THIS DISC!! 

Multiply claimed extents: 

82344 to 82503, claimed by inodes 2220 and 9340 

Unclaimed extents: 

54896 to 54907 
101595 to 101605 

Similarly, any extents claimed by more than one i-node are reported at this time. The 
system issues a report as shown above, where 82344 to 82503 identifies the disk blocks in 
the extent claimed by inodes 2220 and 9340. When an i-node value equals -1, it specifies 
that the free map is one of the i-nodes claiming the extent. If one of the i-node values 
reported is the free map, re-running fsck with the -s option corrects the situation by 
re-building the free map. However, if neither i-node is the free map, then two valid files 
claim the same extent. In this instance you should examine the file associated with each 
i-node and remove one of the files (usually the oldest file is removed). To find the name 
of each file associated with each i-node, enter the following commands: 

/bin/find / -inum 2220 -print 
/bin/find / -inum 9340 -print 

Once you know the name of each file claiming a common extent, you can examine each 
file and remove the file(s) that are improperly claiming the extent. When one of the files 
is removed, its claim on the extent is transferred to the free map. Then, when fsck is 
re-run with the -s option, the situation is corrected, fsck with the -s option must be run 
immediately after removing the file to prevent the operating system from reallocating its 
space to yet another file. A consistent file system contains no multiply-claimed extents. 

Phase 3: Checking the File Attribute File 

In the next phase, fsck attempts to locate orphaned files. First, the list of i-nodes created 
in step 1 above is examined. Any i-node not included in the list is examined to identify 
the disk space it claims. An i-node can claim space and yet not be recognized as a file 
if the i-node exists but has no links from a directory. If the space claimed by the i-node 
is part of the unclaimed blocks list, the file is termed an ''orphan” (how terrible). An 
orphan is an i-node that represents a valid file but has no link from a directory. 
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♦♦Checking the File Attribute File 

The system next examines the size of the orphaned file (i-node). If the size is 0, the 
system asks if it may clear the i-node and restore its extents to the free map. An 
affirmative reply corrects the inconsistency while a negative reply causes no action and 
leaves the file system corrupt. If the size of the orphan is non-zero, the system asks if 
it should attempt to restore the file. An affirmative response causes the orphan’s i-node 
to be linked to the lost+found directory located at the root level of the volume you are 
che(‘king. If you are checking the root file system, this directory is called /lost+found 
and is shipped with your HP-UX system. If you are checking an unmounted file system 
volume, then the lost+found directory is located at that file system’s root level. For 
example, assuming that you have a file system called “/^^f^base”, the directories full 
pathname is “/database/lost+found”. 


Note 

If you initialize and mount an independent file system volume to 
the file system root, you must create the lost+found directory for 
it. Once this directory is created, unmount the volume before 
using fsck. You cannot execute fsck on it unless the lost+found 
directory already exists. 


Phase 4: Checking Extent Maps 

I-nodes are not the only aspects of the file system that can be ‘"orphaned”, and the 
first thing phase 4 does is to check for orphaned extent maps. When an i-node claims 
more than four extents, it must use one or more extent maps to identify the additional 
extents. Occasionally, when a file becomes corrupt, the i-node may be cleared but the 
extent map(s) claimed by the i-node is not cleared. When this happens, an orphaned 
extent map is created. 

♦♦Checking Extent Maps. 

If the orphaned extent map claims blocks listed in the unclaimed block list (created in 
phase 1), and if all orphaned files have been restored, the system asks if you wish to add 
the blocks claimed by the orphaned extent map to the free map. An affirmative response 
causes the claimed blocks to be added to the free map. A negative response causes no 
action; the file system remains corrupt. 
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Phase 5: Checking Link Counts 

The system begins verifying the number of links to each i-node in phase 5. Each i-node 
keeps track of the number of directory entries linked to it. Additionally, as f sck executes, 
it creates a separate list with which to cross check the i-node link count. If the link counts 
disagree, the system displays the messages: 

♦♦Checking Link Counts. 

Wrong link count for inode 3042. 

It*s currently 4 but should be 1. 

Shall I fix it? yes 

where 4 is the link count maintained by the i-node and 1 is the link count created by f sck. 
An affirmative response to the prompt resets the i-node link count such that it agrees 
with the count maintained by f sck. A negative response prohibits corrective action from 
taking place; the file system remains corrupt. 

Phase 6: Checking The Free Map 

If, during any of the previous steps, you have failed to take a suggested corrective action 
(and thus leaving the file system corrupt), the following message is displayed and the 
checks described in this step are not performed: 

♦♦Unable To Check Free Map. 

This message specifies that the file system still has some uncorrected problems. If the 
file system is consistent and no further corrections are needed, the following message is 
displayed and the checks described in this step are not performed: 

♦♦No Need To Check Free Map. 

There are no unclaimed blocks. 

This is an informational message stating that nothing is wrong. If all of the corrective 
actions specified by fsck have been taken, and if the free map is not know to be current, 
fsck displays: 

♦♦Checking The Free Map. 

Shall I return lost blocks to the free map? yes 

Next, the current state of the file system is compared to the disk’s free map. If the system 
finds an inconsistency between the two, a message is displayed specifying that the free 
map is out of date. You are then asked if you wish to update it (the free map). An 
affirmative response causes the system to re-build the free map such that it is consistent 
with the current state of the file system. A negative response causes no corrective action 
to be taken; the file system remains corrupt. 
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Phase 7: Updating Kernel Data Structures 

Finally, the system updates the internal information it keeps about the file system root 
or virtual memory volume, as indicated by the display: 

♦♦Updating kernel data structures. 

If this update fails (the update will always fail when checking an unmounted volume), 
the system displays the message: 

Kernel failed to update its data structures for /dev/rdsk/lsO 

If, as in our example system, the volume being checked is the file system root or the 
virtual memory device, you should re-boot the system at this time. You will get a 
message similar to this: 

Kernel reclaimed 23 blocks for existing virtual objects. 

Do not be alarmed! This is normal for an fsck of the root and virtual memory volume. 
If the update succeeds (or the volume being checked is not mounted), fsck next reports: 

/dev/rdsk/OsO statistics: 

total number of files: 9376 

total number of blocks: 129024 
number of user blocks: 106654 

number of free blocks: 19278 

percent of disc unused: 14 

If the file system has not been fully repaired, the following message is displayed: 

THIS FILE SYSTEM IS NOT COMPLETELY RESTORED. 

You should fully repair the system before allowing access to it. However, some errors 
in the file system are more dangerous than others. Unless the file system contains 
multiply-claimed extents, you can probably use the file system without further corrupting 
the system. If the file system contains multiply-claimed extents, you must correct the 
situation (by re-running fsck). 
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Note 


You should always be able to successfully execute fsck without 
errors before you restore your Series 500 system to normal use. 


Occasionally, a file system is too corrupt to be repaired by fsck. In this instance, you 
must initialize the media and then restore the file system from its last backup. If the 
HP-UX file system is too corrupt to be repaired, you may have to re-install the system 
and then restore the file system from your last backup. In the event that you do not 
have the current installation tapes, you should consult your Sales Office for assistance. 

FSCK and Virtual Memory 

One of the devices that fsck can be called upon to check is the virtual memory device 
(as in our example). Unfortunately, fsck requires a great deal of memory for its own 
use and this means that the file system is often not quiescent when checking the virtual 
memory device. However, consider the following points: 

• fsck reads the free map fairly early in the checking sequence before it gets the space 
to keep track of file system extents. This means that fsck thinks that any existing 
virtual memory extents are unclaimed (and treats them as such). A number of 
these extents may be associated with f sck’s encompassing shell, existing processes, 
and what little memory fsck has already gotten. 

• As fsck grabs more memory, it is not reflected in its internal copy of the free map. 

• When fsck rebuilds the free map, all virtual memory extents are marked as ‘Tree”. 
Although this is a potentially dangerous situation, fsck immediately notifies the 
operating system, which restores the true status of the virtual memory extents in 
the free map. 

Thus, under normal circumstances, it should be safe to run fsck on any virtual memory 
volume. However, if there is any other virtual memory activity occurring on the volume, 
especially while the operating system is updating its virtual memory data structures, the 
volume could be corrupted or destroyed. 
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System Loader Messages 

Introduction 

The system loader is a program which permanently resides in the computer and causes 
the computer to search for and load an operating system. If the computer is unable to 
locate and load the TEST System, (or any operating system), a message is displayed. 
Each of these messages is explained below. Possible causes for many of the messages are 
provided. If the message begins with ERROR:, the system halts after issuing the message. 
If the message begins with NOTE :, the message provides information and the computer 
continues operating. 

If the message you receive indicates a hardware failure, run the Module Self Test or, if 
present, the System Integrity Test before calling your HP Customer Engineer for service. 

Often, the computer attempts to identify the device to which it was “talking” when 
the message was generated. The trailer SELECT CODE NN is appended to the message to 
indicate which select code (I/O port) of the computer caused the message. Select codes 
0 through 7 are on the computer and are controlled by the first I/O processor (lOP). 
Select codes 8 through 15 are on the first I/O expander and are controlled by the second 
lOP. Select codes 16 through 23 are on the second I/O expander and are controlled by 
the third lOP (only 2 lOP’s can be used with the Model 550). 

How the select codes 0 through 7 are associated with the slots in your computer’s I/O 
card cage depends on what model you have: 

• The Model 520 has four I/O slots available which are associated with select codes 
2 through 5, the top one being select code 2. Select codes 0, 1,6, and 7 refer to the 
internal peripherals. 

• The Models 530 and 540 have 71/0 slots available which are associated with select 
codes 0 through 6, the top one being select code 0. Select code 7 refers to the 
internal SCM board. 

• The Model 550 has 7 1/0 slots available which are associated with select codes 0 
through 6, as well as an internal HP-IB card. If the internal HP-IB is used, it is 
counted as select code 5 by default and you only have 6 available slots left (however, 
the HP-IB can be set to be on select codes 0 thru 6). Select code 7 refers to the 
internal SCM board (the internal physical printed circuit board actually contains 
both the HP-IB and SCM functions). 
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On an I/O expander, the upper left slot, when viewed from the rear, is always the lowest 
number select code on that I/O expander. 

As an example, suppose the message: 

NOTE: BAD CARD OR DEVICE: SELECT CODE 18 

is printed. This indicates that the failure is associated with select code 18, which is the 
third slot on the second I/O expander. In this case, either the I/O card in that slot has 
failed its self-test or if it is an HP-IB card connecting a mass storage device, the mass 
storage device failed its self-test. 


Messages 

Loader XXX —informational message identifying the revision of the system loader. This 
message is usually followed by a single line message identifying the operating system the 
computer is attempting to load. 

Testing Memory . . .—informational message that follows the Loader XXX message indi¬ 
cating that the loader is performing memory tests and configuring memory. This can 
take up to 15 seconds. 

Looking for System . . .—informational message that follows the Testing Memory . . . 
message indicating that the loader is searching for an operating system. 

Please mount next volume, informational message. The loader is ready to load another 
portion of the operating system. Mount the volume containing an un- loaded portion 
of the operating system. Volumes may be mounted in any order without affecting the 
loading process. 

SYSTEM NOT FOUND; WILL RETRY IN XXX- unable to find an operating system on any mass 
storage device. The loader will attempt to find an operating system again in XXX seconds. 
Possible causes: mass storage device not powered up, no media in mass storage device, 
wrong disk in disk drive, computer or mass storage device hardware failure, media failure, 
incompatible loader/system revision numbers, etc. 

BAD SYSTEM FILE: SELECT CODE NN —operating system loaded; however, an error has 
been detected in the operating system code during loading. Possible causes: corrupt 
system, media failure, mass storage hardware failure or computer hard- ware failure. 
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NOT ENOUGH USABLE MEMORY; TOTAL IS XXXX The amount of usable memory is too small 
to load the operating system = The total amount of good memory is: XXXX bytes. The 
amount of memory available for the operating system is XXXX— 98 304 bytes. Possible 
causes: corrupt system or hardware (memory) failure. 

BAD CARD OR DEVICE: SELECT CODE NN —informational message. A hardware failure has 
been detected (interface card or mass storage device did not pass Module Self-Test). The 
loader continues searching for an operating system. 

MEDIA/DEVICE NOT READY: SELECT CODE NN —while loading, the media (volume) was re¬ 
moved from the device (e.g. a floppy disk was pulled out of a disk drive), the device went 
offline, or a hardware problem caused the device to become otherwise “not ready”. 

UNRECOVERABLE DATA: SELECT CODE NN part of the operating system is not readable. 
Possible causes: media failure or mass storage hardware failure. 

END OF VOLUME: SELECT CODE NN attempt to address or read past the end of a volume. 
Possible causes: corrupt system, media failure or mass storage device hardware failure. 

CTRLR/UNIT FAULT: SELECT CODE NN- hardware passed initial self-test: however, it failed 
while being used to load the operating system. Possible causes: computer (interface 
card) hardware failure or mass storage device hardware failure. 

10 TIMEOUT: SELECT CODE NN —mass storage device failed to respond fast enough while 
attempting to load from it. Possible causes: computer hardware failure or mass storage 
device hardware failure. 

CS80 DEVICE: SELECT CODE NN—indicates a mass storage device hardware failure. 

TAPE DEVICE: SELECT CODE NN -usually indicates a tape device (HP 7970, HP 7974, 
HP7978) hardware failure. Can also indicate a failure on the HP 271 lOA HP-IB In¬ 
terface. Tape errors covered are: “Command Rejected”, “Interface Busy”, “Rewinding”, 
“Tape Run-Away”, “Data Timing Error”, and “Command Parity Error”. 

HPIB CARD: SELECT CODE NN —transaction to the indicated HPIB interface card was ter¬ 
minated due to a probable interface card failure. 

KBD/SCM NOT FOUND, indicates a computer hardware failure (keyboard) on a Model 520 
Computer; computer hardware failure (system control module) on a Model 530, 540 or 
550 Computer. 
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BAD 10 BUS: SELECT CODE NN —indicates a computer hardware failure on the computer’s 
first I/O Processor. 

BAD NVM: SELECT CODE NN —indicates that NVM (Non-volatile Memory) failed self-test. 
Possible cause: computer hardware error. 

BAD RTC: SELECT CODE NN- indicates that the computer’s built-in real time clock is not 
functioning. 

BAD SP: SELECT CODE NN —indicates that the Model 530/540 Computer’s service proces¬ 
sor failed self-test. 
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Glossary 


The following terms and definitions are defined as they apply to the Series 500 HP-UX 
operating system. 

address 

In the context of peripheral devices, a set of values which specify the location of an I/O 
device to the computer. The address is composed of up to four elements: select code, 
bus address, unit number and volume number. You can read about addresses in the 
Peripheral Installation Guide and in “Adding/Moving Peripherals” in Chapter 5 of this 
manual. 

Asynchronous Interface (ASI) 

With the exception of an ITE as found on a Model 520 or on a Model 550 with the HP 
98700 display device, every terminal on your system must communicate with the host 
via either an ASI or MUX card. The ASI and MUX cards communicate in an RS-232C 
compatible protocol, and support the standard 25 pin connector. 

block 

The fundamental unit of information Series 500 HP-UX uses for access and storage 
allocation on a mass storage medium (such as a CS/80 disc). A block is usually 1024 
bytes. 

block mode 

Buffered I/O: data is transferred one block at a time. Block size for buffered I/O is 
not the same as block size on the file system. Block size for block mode is defined as 
BLKDEV.IOSIZE in /usr/include/sys/param.h. 

boot or boot-up 

The process of loading, initializing and running an operating system. 

boot area 

Each Structured Directory Format (SDF) volume has one boot area consisting of zero or 
more contiguous logical blocks. This area contains the kernel, device drivers and some 
optional products if installed, and is read into the memory of your Series 500 computer 
by the boot ROM upon power up. The boot area is completely outside the file area, and 
cannot be used for data storage. Its size is determined when the volume is initialized. 
To change the size of a boot area you must re-initialize the volume. 
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boot ROM 

A program residing in ROM (Read Only Memory) that executes each time the computer 
is powered-up. The function of the boot ROM is to run tests on the computer’s hardware, 
find all devices accessible through the computer and then load either a specified operating 
system or the first operating system found according to a specific search algorithm. The 
bootstrap program uses the boot ROM’s mass storage drivers to load and pass control to 
the kernel. When the kernel gains control, it completes the job of bringing up the HP-UX 
operating system. Details of the boot ROM’s search algorithm are given in chapter 4 
(“System Boot and Login”). 

Depending on your boot ROM version, the boot ROM displays may differ slightly from 
those shown in this manual; any differences between boot ROM versions are noted in 
this manual when the topic in question is discussed. The boot ROM identifies its version 
when power is applied to the computer. 

bus address 

Part of an address used for devices, especially devices on an HP-IB (HP Interface Bus); 
a number determined by the switch setting on a peripheral which allows the computer 
to distinguish between two devices connected to the same interface. A bus address is 
sometimes called a “device address”, and no two devices on the same HP-IB can have 
the same bus address. 

connect session 

This denotes the period of time in which a user is connected to the system. It starts 
when the user logs in and finishes when the user logs out. 

cron 

This process wakes up every minute to execute commands at specified dates and times, 
according to instructions in files contained in the directory /usr/spool/cron/croutabs. 
See the cron(lM) and crontab(l) entries in the HP-UX Reference for more details. 

CS/80 

A family of mass storage devices that communicate with a computer via the CS/80 
(Command Set ’80) or SS/80 (Sub Set ’80) command set. A list of CS/80 and SS/80 
devices supported on HP-UX can be found in the HP 9000 Series 500 Configuration 
Information and Order Guide supplied with your system. 
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destination device 

The mass storage device on which HP-UX is to be installed. The destination device 
miist be a CS/80 device other than the HP 9000 Model 520’s built-in flexible disc drive 
or its built-in Winchester disc drive. The built-in cartridge tape drive of a CS/80 device 
should not be used as a destination device when installing the system. 

driver number 

A pointer to the part of the kernel needed to use the device. The driver number, for a 
particular device, can be found in the tables in “Adding/Moving Peripheral Devices” in 
the “Toolbox” chapter. 

disc 

The term used for a collection of recording platters contained in a single disc drive. Disc 
is synonymous with disc pack, 

/etc/rc 

This is the system initialization shell script. The actions that it performs depend on the 
state in which it is invoked. To automatically start System Accounting whenever the 
system is switched to multi-user mode, a command must be added to re. See the chapter 
“System Boot and Login” in this manual, and rc(8) in the HP-UX Reference for more 
details on the use of rc, 

/etc/shutdown 

A shell script that has the primary function of terminating all currently running processes 
in an orderly and cautious manner. See shutdown(8) for details on this shell. 

file 

A discrete collection of information described by an inode and residing on a mass storage 
medium. 

fileset 

A collection of related files on an installation or an update tape. 

file types 

Several file types are recognized by HP-UX. The file type is established at the time of 
the file’s creation. The types are: 

• Regular files - Contains a stream of bytes. Characters can be either ASCII or non- 
ASCII. This is generally the type of file a user considers to be a file: object code, 
text files, nroff files, etc. 
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• Directory - HP-UX treats directories like regular files, with the exception that 
writing directly to directories is not allowed. Directories contain information about 
other files. 

• Block special files - Device files that buffer the I/O. Reads and writes to block 
devices are done in block mode. 

• Character special files - Device files that do not buffer the I/O. Reads and writes 
to character devices are in raw mode. 

• Network special files - contain the address of another system. 

• Pipes - A temporary file used with command pipelines. When you use a pipeline, 
HP-UX creates a temporary buffer to store information between the two commands. 
This buffer is a file, and is called a pipe. 

• FIFO - A named pipe. A FIFO (First In/First Out) has a directory entry and 
allows processes to send data back and forth. 

file system 

The organization of files and directories, associated with a block special file, on a hard 
disc. The SDF file system is an implementation of the HP-UX directory structure. 

HP-UX directory structure 

The hierarchical grouping of directories and files on HP-UX. 

HP 88140 cartridge tape drive 

The built-in cartridge tape drive of a CS/80 or SS/80 disc drive. 

inode 

A data structure containing information about a file such as file type, pointers to data, 
owner, group, and protection information. 

Internal Terminal Emulator (ITE) 

The “device driver” code contained in the HP-UX kernel and associated with the built-in 
keyboard and display on the Series 500 Model 520. or with the HP 98700 display device 
configuration on the Model 550. 
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Kbyte or kilobyte 

1024 bytes. 

kernel 

The core of the HP-UX operating system. The kernel is the compiled code responsible 
for managing the computer’s resources; it performs such functions as allocating memory 
and scheduling programs for execution. The kernel resides in RAM (Random Access 
Memory) whenever HP-UX is running. 

LIF 

Logical Interchange Format. LIF is Hewlett-Packard’s standard file format, used for 
transferring files between Hewlett-Packard systems. Since LIF is a standard, files with 
LIF format can easily be transferred between different Hewlett-Packard computers (see 
the LIF(5) entries in the HP-UX Reference. 

login 

The process of a user gaining access to HP-UX. This process consists of entering a valid 
user name and its associated password (if one exists). 

major number 

Same as driver number. 

Mbyte or megabyte 

1 048 576 bytes, 

minor number 

A hexadecimal number made up of a select code, bus address, unit number, and volume 
number of the device. 

multi-user state 

A state of HP-UX when terminals in addition to the system console allow communication 
between the system and its users. The multi-user state (not to be confused with a multi¬ 
user system) is usually state 2. 

MUX 

An interface card which communicates via the backplane to the I/O processor of your 
Series 500. MUX is an abbreviation for Asynchronous Multiplexer. There are two flavors 
of MUX cards available for the Series 500: the HP 27130A 8-channel MUX card, and 
the HP 27140A 6-channel modem MUX which supports modem protocol. Each channel 
is an RS-232C port which is normally associated with a /dev/ttyXX file. 
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path name 

A series of directory names separated by / characters, and ending in a directory name 
or a file name. 


process 

A process is the environment in which a program (or command) executes. It includes the 
program’s code, data, status of open files, value of variables, and the directory in which 
the process resides. For example, whenever you execute an HP-UX command, you are 
creating a process; whenever you log in, you create a process. For additional information 
on processes, read the chapter “Concepts.” 

raw mode 

Unbuffered I/O. Data is transferred directly between the device and the user program 
requesting the I/O, rather than going through the file system buffer cache. 

root 

Root refers to the highest level directory (root directory or /). Root also refers to the 
superuser login. 

root volume 

The mass storage volume upon which the root (i.e. /) directory resides. A disc may be 
marked as the root volume but not have a boot area. See the description of the boot 
ROM’s search algorithm in chapter 4 (“System Boot and Login”). 

select code 

Part of an address used for devices; a number determined by which slot in the I/O bus 
a particular interface card is inserted. Each interface card is in turn connected to a 
peripheral. Multiple peripherals connected to the same interface card share the same 
select code. 

shell 

A program that interfaces between the user and the operating system. HP-supported 
shells are: 

/bin/sh 

/bin/csh 

/bin/rsh 
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single-user state 

A state of HP-UX when the system console provides the only communication mechanism 
between the system and its users. 

source device 

The mass storage device from which HP-UX is installed. The source device must be a 
CS/80 cartridge tape drive. 

special file 

Often called a device file, this is a file associated with an I/O device. Special files are 
read and written just like ordinary files, but requests to read or write result in activation 
of the associated device. These files normally reside in the /dev directory. 

superblock 

A data structure containing global information about the file system. 

system console 

A keyboard and display (or terminal) given a unique status by HP-UX and associated 
with the special device file /dev/console. All boot ROM error messages (messages sent 
prior to loading HP-UX), HP-UX system error messages, and certain system status 
messages are sent to the system console. Under certain conditions (for example, the 
single-user state), the system console provides the only mechanism for communicating 
with HP-UX. 

unit number 

Part of an address used for devices; a number whose meaning is software- and device¬ 
dependent but which is often used to specify a particular disc drive in a device with 
a multi-drive controller. When referring to single-controller integrated disc/tape or 
disc/flexible disc drive, a unit is used to distinguish between disc and cartridge tape 
drives or hard disc and flexible disc drive. 

The unit number also selects a single partition on the 913x series. 

volume number 

Part of an address used for devices; a number whose meaning is software- and device- 
dependent but which is often used to specify a particular volume on a multi-volume disc 
drive. The volume number is also used to inform the device driver of special handling 
semantics (such as printer drivers skipping over perforations). 
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